Какую БД предпочтительней использовать для хранения и обработки больших объемов данных?

Question

[marenco_victor]

Добрый день, господа!

Настала пора писать дипломную работу. В процессе появился вопрос, на который мне не удалось найти однозначного ответа. Суть в том, какую БД(реляционную или не реляционную) предпочтительней выбрать для работы с большими объемами данных. Эти данные получают при проведении испытаний различного рода сложных технических систем (двигатели ракет, самолетов и т.д.) Тоесть объемы получаемых данных очень большие. Как их хранить чтобы удобно и быстро читать/писать и возможно проводить какие-либо манипуляции по обработке?

Хочется узнать мнение более опытных людей в данном вопросе.

Comments

[Илья Ерохин]

зависит от того что такое в вашем понимании "очень большие" объемы, каков характер данных, как будете данные обрабатывать, сколько будет железа, и какая нужна скорость обработки.

Answer 1

[tovogukA]

Раз уж у вас это дипломный проект, то вникните в суть.

Насчет того, что здесь написали про ElasticSearch и NoSQL - это просто дань моде или человек, вам ответивший, совсем не понимает о чем речь.

Разные БД масштабируются с разным успехом. Это да. И вроде бы, RDBMS, в общем случае, масштабируются хуже, чем NoSQL. Однако, есть ситуации - когда, к примеру, NoSQL хороши, а есть и такие, где они плохи на масштабах и лучше бы выбрали RDBMS
https://habrahabr.ru/post/231213/

Но без знания о каких именно данных и о каком объеме идет речь, сказать что-либо конкретное невозможно. Также о какой именно нагрузке - выборка данных, добавление данных, хранение данных. Вполне возможно, что прекрасно подойдет и SQL.

Именно умение выбрать. сконфигурировать и напрограммировать под конкретную задачу под конкретную базу данных - это и есть то, за что специалисты получают большие деньги.

А вот это голословное - нужно брать NoSQL и точка - это ответ джуниора.

Comments

[marenco_victor]

tovogukA, благодарю за достаточно развернутый ответ

[tovogukA]

marenco_victor: То что люди называют "большие объемы данных" для современных БД - тьфу. Скажем, если речь идет о миллионах записей, то это тьфу и для MySQL.
А вот если речь идет о записи сотен тысяч показаний в секунду - то я бы выбрал Tarantool.
И т.д. и т.п.

[marenco_victor]

tovogukA: Да, речь идет о сотнях тысяч показаний в секунду, которые ни при каких условиях нельзя потерять

[tovogukA]

Имеется ввиду не чистый Тарантул, а Тарантул с Софией.

[tovogukA]

marenco_victor: InfluenceDB, Tarantool+Sophia

Answer 2

[Александр Ананьев]

Для таких целей бесплатных продуктов нет. Есть специализированные решения, навроде IndustrialSQL или Proficy Historian. Такие решения работают либо поверх MS SQL Server, либо это собственное проприетарное решение.

Answer 3

[Sergey Syrovatchenko]

Вначале нужно определиться с тем, что Вы хотите построить. Судя по Вашему описанию это будет Data Warehouse. Если Вам нужно делать сложный анализ, то выбирать можно среди SQL Server и Oracle. Данныt СУБД имеют очень хороший оптимизатор запросов и много разных функций по аналитике. Плюс в SQL Server (про оракл не скажу точно) есть columnstore индексы, которые в Вашем случае могут снизить размер Вашего файлового хранилища. Много чего можно еще сказать, но задача Вами поставлена размыто (какой прирост данных, структура и тд)

Если заморачиваться с реляционностью не сильно хочется, то обратите внимание на NoSQL.

Answer 4

[Drum Kit]

Для больших данных можете использовать elasticsearch как no sql базу данных

Answer 5

[res2001]

Если требуется быстрая запись в базу больших объемов информации, то скорее всего придется делать через промежуточный файл (файл куда пишете поток данных в "сыром" виде), т.к. запись в БД это обычно довольно затратная операция.
Потом этот файл скармливаете отдельной программе, которая будет его писать в базу, по расписанию или как-то синхронизировать процессы, но уже со скоростью, которую способна выдать выбранная БД.

Comments

[mzG2Gzm]

т.к. запись в БД это обычно довольно затратная операция.

Есть системы, заточенные за запись, например, Cassandra