CC BY
58
Тестировщики, которые не умеют (или не хотят) программировать, используют Selenium IDE как самостоятельный продукт, без преобразования записанных сценариев в программный код. Это, конечно, не позволяет разрабатывать достаточно сложные тестовые наборы, но некоторым хватает и простых линейных сценариев.
Таким образом, наиболее оптимальным решением является Selenium WebDriver, так как сценарий поведения всех сборщиков данных будет одинаковым.
Литература
1. Википедия. API. [Электронный ресурс]. Режим доступа: https://ru.wikipedia.org/wiki/API/ (дата обращения: 08.12.2016).
2. Веб-сайт ВКонтакте. Работа с API. [Электронный ресурс]. Режим доступа: https://vk.com/dev/apiusage/ (дата обращения: 07.12.2016).
3. Stanford University. Web scraping with Beautiful Soup. [Electronic resource] URL: https://ru.wikipedia.org/wiki/Selenium/ (date of access: 08.12.2016).
4. Википедия. Selenium. [Электронный ресурс]. Режим доступа: https://ru.wikipedia.org/wiki/Selenium/ (дата обращения: 06.12.2016).
THE ANALYSYS STORING SOCIAL DATA FROM THE INTERNET METHODS Sukhanov А.1, Maratkanov А.2 (Russian Federation) АНАЛИЗ СПОСОБОВ ХРАНЕНИЯ СОЦИАЛЬНЫХ ДАННЫХ ИЗ СЕТИ
ИНТЕРНЕТ
Суханов А. А.1, Маратканов А. С.2 (Российская Федерация)
'Суханов Александр Александрович / Sukhanov Aleksandr — магистрант; 2Маратканов Александр Сергеевич /Maratkanov Aleksandr — магистрант, кафедра компьютерных систем и сетей, факультет информатики и систем управления, Московский государственный технический университет им. Н. Э. Баумана, г. Москва
Abstract: the problem of collecting social data becomes more urgent. Storage of that data becomes a problem. The specificity of that data structures and architecture problems in common database management systems are the weaknesses of many databases. Basic SQL and NoSQL solutions that can be used for these purposes are discussed in the article. Also comparison between most popular solutions like PostgreSQL and MySQL was made. Also detail analysis of most popular NoSQL databases was made. Advantages and disadvantages of storing types in NoSQL databases were also considered.
Аннотация: на данный момент задача сбора социальных данных приобретает всю большую актуальность. Однако это ставит такую проблему, как хранение этих данных. Из-за специфичности подобных данных, а также из-за того, что многие СУБД не были проектированы для хранения больших массивов часто обновляющихся и слабо структурированных данных, особое внимание требуется уделить выбору СУБД. В статье рассмотрены основные SQL и NoSQL решения, которые могут быть использованы для подобных целей. Кроме того, проведено сравнение этих решений.
Keywords: social data, SQL, NoSQL, databases.
Ключевые слова: социальные данные, SQL, NoSQL, базы данных.
1. Анализ SQL- решений для хранения данных
SQL остаётся единственным механизмом связи между прикладным программным обеспечением и базой данных. В то же время современные СУБД, а также информационные системы, использующие СУБД, предоставляют пользователю развитые средства визуального построения запросов [1].
Наиболее распространенными бесплатными решениями являются MySQL и PostgreSQL, поэтому далее мы постараемся их сравнить по следующим параметрам:
• Репликация.
• Документация.
• Стандарты.
Более подробное сравнение MySQL и PostgreSQL приведено в таблице 1.
Тип сравнения Роэ1§ге80Ь MySQL
Репликация Основное преимущество -физические репликации. PostgreSQL сохраняет запросы, которые потом попадают в журнал и после этого журнал используется для репликации. Этот же журнал используется и для восстановления после сбоев, то есть данный метод уже прошел проверку временем. Кроме того существует триггерная репликация. Основыне проблемы: корректность работы, производительность репликации и стабильность репликации. К сожалению, в MySQL репликация недостаточно продумана и не может быть полностью использована из-за поддержки так называемых storage engine, то есть подключаемых движков. Из-за этого возникают проблемы с транзакциями между таблицами с разными storage engine.
Сложность администрирования Сложности администрирования сглаживаются засчет полноты официальной документации и большого размера PostgreSQL-сообщества в сети. Более простая в администрировании СУБД, однако это во многом связано с достаточно ограниченным функционалом.
Стандарты SQL-92 SQL-98 SQL-2003 Идет работа над поддержкой стандарта SQL-2011 SQL-92
Документация Документация PostgreSQL является наиболее объемной среди всех СУБД. Отчасти это объясняется ее повсеместным распространением. Кроме наличия подробной официальной документации также существует достаточное количество информации по правилам проектирования и оптимизированию PostgreSQL баз данных. Документация MySQL оставляет желать лучшего. Несмотря на наличие официальной документации, для понимания работы СУБД часто приходится не только обращаться к дополнительным источникам, но и разбираться в арихтекутуре СУБД. Из-за этого проектирования хранилищ для большого числа данных упирается в то, что можно допустить ошибки просто из-за того, что какие-либо моменты не были освещены в документации.
2. Анализ NoSQL решений для хранения данных
Традиционные СУБД ориентируются на требования ACID к транзакционной системе: атомарность (англ. atomicity), согласованность (англ. consistency), изолированность (англ. isolation), надёжность (англ. durability), тогда как в NoSQL вместо ACID может рассматриваться набор свойств BASE [3]:
• базовая доступность (англ. basic availability) — каждый запрос гарантированно завершается (успешно или безуспешно);
• гибкое состояние (англ. soft state) — состояние системы может изменяться со временем, даже без ввода новых данных, для достижения согласования данных;
• согласованность в конечном счёте (англ. eventual consistency) — данные могут быть некоторое время рассогласованы, но приходят к согласованию через некоторое время.
Далее представлен анализ по таким критериям как масштабируемость, модель данных и запросов и системе хранения данных.
2.1. Масштабируемость
Под масштабируемостью часто подразумевается репликация, поэтому в данном контексте имеется ввиду автоматическое распределение данных между несколькими серверами.
В распределенной базе данных следует обращать внимание на следующие параметры: поддержка нескольких датацентров и возможность добавления новых машин в работающий кластер прозрачно для ваших приложений.
Прозрачное добавление в кластер Поддержка нескольких датацентров
Cassandra Есть Есть
HBase Есть Нет
RIAK Есть Есть
Scalaris Есть Нет
Voldemort Нет Требуется ручная оптимизация
2.2. Модель данных и запросов
Существует огромное многообразие моделей данных и API запросов в NoSQL базах данных.
Таблица 3. Модели данных и API запросов NOSQL баз данных
Модель данных API запросов
Cassandra Семейства столбцов Thrift
CouchDB Документы Map/Reduse
HBase Семейства столбцов Thrif,REST
MongoDB Документы Cursor
Neo4J Графы Graph
Redis Коллекции Collection
RIAK Документы Nested cashes, REST
Scalaris Ключ/значение Get/Put
Tokyo Cabinet Ключ/значение Get/Put
Voldemort Ключ/значение Get/Put
Документо-ориентированные базы данных - это по существу следующий уровень систем ключ/значение, позволяющий связывать вложенные данные с каждым ключом. Поддержка таких запросов более эффективна, чем просто возвращение всего BLOB каждый раз.
Neo4J обладает поистине уникальной моделью данных, храня объекты и связи в качестве узлов и ребер графа. Для запросов, которые соответствуют этой модели (например, иерархических данных) они могут быть в тысячу раз быстрее, чем альтернативные варианты.
Scalaris уникальна в использовании распределенных транзакций между несколькими ключами. Обсуждение компромиссов между последовательностью и наличием свободных мест также необходимо учитывать при оценке в распределенных системах.
2.3. Система хранения данных
Под системой хранения данных подразумевается то, как данные хранятся внутри системы.
Таблица 4. Модели данных NOSQL баз данных
Название Модель данных
Cassandra Memtable/SStable
CouchDB Append-only-B-Tree
HBase Memtable/SStable on HDFS
MongoDB B-Tree
Neo4J On-disk linked lists
Redis In-memory with backgorund snapshots
RIAK Hash
Scalaris In-memory-only
Tokyo Cabinet Hash/B-Tree
Voldemort Pluggable
Система хранения данных может сказать нам многое о том, какие нагрузки база может нормально выдерживать.
Таким образом, наиболее оптимальным решением для рассматриваемой системы является связка SQL и NOSQL решения. В качестве СУБД было принято решение выбрать Cassandra и PostgreSQL.
Литература
1. Введение в SQL. SQL: Обзор. [Электронный ресурс]. Режим доступа: http://www.mysql.ru/docs/gruber/mg 02.html/ (дата обращения: 08.12.2016).
2. Хабрахабр. PostgreSQL vs MySQL. [Электронный ресурс]. Режим доступа: https://habrahabr.ru/company/mailru/blog/248845/ (дата обращения: 07.12.2016).
3. Википедия. NoSQL. [Электронный ресурс]. Режим доступа: https://ru.wikipedia.org/wiki/NoSQL/ (дата обращения: 08.12.2016).
4. Хабрахабр. Обзор NoSQL систем. [Электронный ресурс]. Режим доступа: https://habrahabr.ru/post/77909/ (дата обращения: 06.12.2016).
DESIGN METHODS OF PILED-RAFT FOUNDATION UNDER THE VERTICAL
LOAD
Tsvetkova P. (Russian Federation) МЕТОДИКИ РАСЧЕТА КОМПЛЕКСНОГО ПЛИТНО-СВАЙНОГО ФУНДАМЕНТА ПРИ ДЕЙСТВИИ ВЕРТИКАЛЬНОЙ НАГРУЗКИ Цветкова П. Ю. (Российская Федерация)
Цветкова Полина Юрьевна / Tsvetkova Polina — магистрант,
кафедра инженерной геологии, оснований и фундаментов, факультет промышленного и гражданского строительства, Самарский государственный технический университет, г. Самара
Abstract: complex piled-raft foundation (CPRF) is an effective building construction, which allows building in unsuitable geological conditions. The construction of the foundation consists of raft and piles. The main factor of the foundation behavior is the interaction between the construction elements. The elements of the construction and the interaction factors are observed in the paper. The main methods of the designing the construction under the vertical load and its comparison study are represented as well.
Аннотация: комплексный плитно-свайный фундамент (КПСФ) - эффективная строительная конструкция, которая позволяет производить строительство в осложненных инженерно-геологических условиях. Конструкция фундамента представляет собой плиту, опертую на сваи. Ключевым фактором работы конструкции является взаимодействие элементов плитно-свайного фундамента (ПСФ). В статье указаны элементы конструкции КПСФ, представлены факторы их взаимодействия. Также приведены основные методы расчета ПСФ при действии вертикальной нагрузки, сравнительный анализ рассматриваемых методов.
Keywords: piled-raft foundation, pile, raft, settlements.
Ключевые слова: комплексный плитно-свайный фундамент, свая, фундаментная плита, осадки.
Распределение напряжений в ПСФ зависит от взаимодействия между сваями, плитой и грунтом основания, а, следовательно, эти факторы определяют поведение ПСФ. В таблице № 1 представлены основные подходы определения этих взаимодействий [1].
Таблица 1. Оценка факторов взаимодействия между элементами фундамента
Подход Тип взаимодействия Примечание
Паулос и Дэвис свая-свая -Учитывается дополнительная осадка сваи от влияния соседней сваи
Паулос свая-свая -Влияние соседней сваи не отражено -Учитывается дополнительная осадка сваи от нагрузок соседних свай
Рандольф свая-плита -Учитывается дополнительная осадка цилиндрически жесткой плиты от сваи -Не учитывается изменение модуля упругости грунта вдоль боковой поверхности сваи и гибкость плиты
Рандольф свая-плита -Учитывается модуль упругости грунта вдоль боковой поверхности сваи, под пятой сваи и вокруг оголовка -Не учитывается гибкость плиты
Клэнси и Рандольф свая-плита -Необходимо определить осадку фундамента и величину нагрузки, передаваемую на сваи -Учитывается гибкость плиты
