Clusterix-подобные СУБД класса Big Data

Коммерческие OLAP-системы экономически недоступны организациям с ограниченными финансовыми возможностями. Аналитическую обработку данных значительных объемов в этих организациях можно осуществить с использованием open source программных систем на экономичной кластерной платформе. Ранее созданные Clusterix-подобные СУБД, использующие регулярный план обработки запросов, были недостаточно эффективны. Поэтому исследования по таким системам были развиты с ориентиром на полную загрузку процессорных ядер и применение GPU-акселерации (системы Clusterix-N, N – от New) вплоть до разработки системы, сравнимой по эффективности с открытой зарубежной системой Spark, полагаемой в настоящее время наиболее перспективной. За основу развития была принята методология конструктивного моделирования систем.

Объемы баз данных в сотни GB и более нередки для относительно небольших предприятий с ограниченными финансовыми возможностями. Приобретение такими организациями экономичных вычислительных кластеров и специализированного ПО СУБД консервативного типа (с эпизодическим обновлением данных) делает возможной для них своевременную обработку накопленных данных. Для консервативных СУБД свойственна OLAP нагрузка, характеризующаяся высоким удельным весом сложных запросов типа «селекция – проекция – соединение», оперирующих множеством таблиц с большим числом операций соединения. Разработки в этом направлении ведутся. Коммерческие СУБД обладают высокой производительностью и надежностью, но чрезмерно большой стоимостью. Так, СУБД MS SQL Server 2016 на одном сервере Lenovo x3950X6 имеет совокупную стоимость системы $2 634 342 (сервер ~$1,5 млн. + ПО ~$1 млн.). СУБД Oracle Database с расширением для OLAP и лицензией на 384 ядра обойдется ~ в $9 млн. Плюс стоимость аппаратуры (Exadata) ~$1,5 млн.

Удачной альтернативой дорогостоящим параллельным СУБД в области больших данных являются свободно распространяемые зарубежные разработки с открытым исходным кодом Hadoop и Spark. Обе системы высокопроизводительны, хорошо масштабируются, и их требования к аппаратной платформе весьма скромные. Это делает Hadoop и Spark перспективными системами для аналитической обработки больших массивов данных. Новые отечественные СУБД следует создавать на базе готовых СУБД с открытым кодом и свободной лицензией, поддерживаемых международным сообществом. Этому требованию удовлетворяет открытая версия отечествен-ной разработки Postgres Pro. Но она – одноузловая, а потому – недостаточно производительная.

Созданные ранее исследовательские версии систем Clusterix и Clusterix-M были малоэффективны. Надо было искать пути повышения эффективности Clusterix-подобных систем. Основной задачей данной работы является анализ возможностей реализации экономичных консервативных СУБД повышенных объемов, сравнимых по эффективности (по критерию производительность/стоимость) с системой Spark при обработке потока запросов к БД объемом в сотни GB и более на сравнительно недорогих кластерных платформах с использованием регулярного плана обработки запросов, применением средств MySQL и GPU-акселераторов на исполнительном уровне. MySQL позволяет использовать различные «движки» и имеет систему расширений. Эти особенности упрощают и ускоряют разработку системы в сравнении с использованием PostgreSQL.

И все же по значениям T, M и σ СУБД Clusterix-N заметно уступает системе Spark. Процессы передачи данных, удаления отношений и загрузки данных в MySQL остаются достаточно медленными. Следует ожидать значительного ускорения интерконнекта при переходе на работу со сжатыми базами данных. Это дополнительно повысит эффективность, ибо увеличит объемы БД, допустимые для бездисковой обработки при заданном числе узлов.

#образование #наука

[МихаилЖуков-ел]

Есть ли у вас
"нечеткие запросы".?
Основа логики - двоичная?

[ИванЛягалов-бй]

Здравствуйте!
В четвертой итерации IS - моделирования говорится, что загрузку данных в MySQL можно увеличением числа ядер.
Как это можно сделать?
Также возник вопрос по поводу внешнего конвейера select-project. Есть ли какое то оптимальное значение продолжительности при котором не будет заметного снижения в производительности?

[kath]

Здравствуйте, а не скажется ли такое ускорение операций на доступности системы в целом? Или же этот вопрос решается как раз в спецдвижках MySQL?

[hllrdm]

Здравствуйте.
С момента выхода данного доклада прошло 3 года, в связи с этим хотел бы задавать Вам вопрос — в конце данного доклада Вы говорите, что для MySQL процессы удаления и загрузки данных остаются медленными, в связи с тем, что все ядра загружаются в начале итераций, а дальнейшие действия производятся на одном ядре. Для решения этой проблемы требуется разработка специальных движков MySQL. В современной реализации MySQL имеется возможность в ускорении процессов передачи данных и тп. Или данные движки были Вами разработаны в рамках других задач? Решена ли данная проблема на данных момент?

[chelios]

Здравствуйте, Как вам альтернатива для MySQL, например движки Percona? Percona Server является бесплатной альтернативой MySQL. Может ли Percona или еще какие то альтернативные движки для MySQL увеличить скорость разных процессов, загрузки данных и передачи данных. Хотелось бы узнать об этом по подробнее в ближайшем будущем. Очень интересное и полезное видео.

[nikivalle]

Доброго времени суток,
Возможно ли в ближайшие годы создание более дешевых и доступных СУБД? Или появление совершенно новых архитектур для СУБД отличающиеся от существующих (в том числе и Spark)?
Возможно ли для SMP-узлов применение более 2х процессоров? И по моему мнению для таких систем применение операционной системы Windows не рациональна, гораздо эффективнее использовать Linux по ряду причин. Linux значительно меньше подвержен внешним воздействиям, он бесплатный и т.д.