На каких объемах данных реляционные БД перестают работать?

Question

[dbratus]

Мы проектируем систему, которая в одной из таблиц, в год, должна накапливать более 52.5 миллиардов записей общим объемом 2.7 Tb (если учитывать только полезную нагрузку). То есть, очень много записей с полезной нагрузкой 52 байта на запись. Сейчас мы думаем над хранилищем данных. Заказчик предлагает запихнуть это все в MS SQL 2008, но мне это категорически не нравится, то есть я почти уверен что MS SQL не потянет, но мне нужны доказательства. Поэтому вопрос, собственно: существуют ли независимые опубликованные данные по предельным нагрузкам на различные реляционные БД в том числе и MS SQL? (на английском) Я видел много сравнений MySQL с MongoDB, Cassandra и т.д., но сравнений с MS SQL найти не могу.

Заранее спасибо.

Answer 1

[Григорий Перетяка]

А что значит не потянет?

Размер таблицы в MS SQL ограничен только размером диска.

Другой вопрос — обработка данных, будет медленно, возможно будут ошибки, но это проблема настроек или несоответствие запрашиваемых объемов данных размеру оперативной памяти. Первая проблема с помощью гугла или довольно дешевого специалиста легко решается, а вторую все равно придется исправлять в клиенте независимо от базы.

Если key-value вас устраивает, то такие движки конечно же будут работать на порядок быстрее, есть куча популярных.

Тут я должен был сказать, что если другая модель не SQL более оптимально описывает ваши данные, то лучше использовать ее. Но такие базы, пока, не сравнятся по популярности с реляционными и нет исчерпывающей информации по всем возможным проблемам. Кроме того, на мой взгляд, производительность там также не очень откатана и вот там вполне может «не потянуть» внезапно и по непонятным причинам. В общем я бы рекомендовал такой вариант только если у вас какой-то совсем запущенный случай, который никак приемлемо не решить с помощью реляционной базы. А просто так на таких объемах я бы не экспериментировал.

И вообще все эти тесты — фигня. Единственный нормальный тест — это создать вашу таблицу на двух движках, заполнить демо-данными и протестировать с реальными запросами и под нагрузкой близкой к ожидаемой. Хотя и это не дает полной картины, есть еще такие нюансы как: надежность, горячие бэкапы или даже зеркало, если потеря даже последних данных критична, масштабируемость, итд.

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

Answer 2

[dbmaster]

Как говорила моя старая знакомая, нужно сесть и посчитать.

Comments

[dbmaster]

Извиняюсь — сорвалось.

Узнайте у заказчика почему он хочет именно SqlServer — это поможет вам выборе технологии и аргументации.

SQL Server сам по себе плохо масштабируется (scale out).

Купить железа и лицензий, и обеспечить SLA (тут опять же нужно уточнить) можно — весь вопрос в цене.
Небольшие расчёты тут www.codinghorror.com/blog/2009/06/scaling-up-vs-scaling-out-hidden-costs.html

Очень много факторов влияет на выбор хранилища:

* уже существующий софт и команда
* как данные приходят (real-time vs. etl)
* какие запросы и вычисления нужны (olap vs oltp)
* нужны ли транзакции
* как будут осуществляться бакапы
* нужна ли отказоустойчивость (clusters / mirroring / etc)
* какие технологии будут использоваться для обработки данных
* стоимость поддержки (Microsoft vs. other Company)

Одно могу гарантировать — при таком объёме данных танцы с бубнами на любых операциях в SQL Server вам гарантированны.
Банальные select / update / delete превращаются в сложные метамарфозы — это из моего опыта.

Пару линков, которые возможно помогут:

www.brentozar.com/archive/2011/06/scaling-sql-server-growing-out/
stackoverflow.com/questions/3287966/reasons-for-and-against-moving-from-sql-server-to-mongodb

Прикиньте стоимость нескольких решений — и убедите заказчика потратить денег на POC.

[dbmaster]

Есть ещё такой вариант — Microsoft прикручивает Hadoop к Sql Server — к сожалению пока не пробовал.

www.microsoft.com/sqlserver/en/us/solutions-technologies/business-intelligence/big-data-solution.aspx

[dbratus]

Спасибо за ответ.

База OLTP. Транзакции не нужны. То есть UPDATE-ов по этому делу вообще не будет, толко INSERT и SELECT. Команды, железа, лицензий пока нет, поэтому есть пока некоторая свобода выбора. В общем, пока задача — определить, что в принципе справится с такими данными и выбрать наименее затратный вариант.

Answer 3

[Zorkus]

Ну вообще говоря, 2.7 Тб само по себе не так много (телекомы используют гораздо большего объема базы). Мы использовали базы около 3 терабайт на оракле, сначала два обычных среднего уровня сервера в RAC, потом пробовали Exadata DB Machine Quarter Rack (http://www.oracle.com/us/products/database/exadata-database-machine/overview/index.html — прочитайте, зверь-машина), все нормально работала.

Ключевые проблемы:

— partitioning и разделение это таблицы на отдельные секции, которые лежат на разных жестких дисках в рейде (критичные партиции, где лежат наиоболее горячие данные, можно положить на SSD)
— будет ли идти большое количество «живых» запросов агрегирующих данных на высоком уровне? Запросы к таблице в несколько миллиардов записей выполняются вполне быстро, если они строго идут по partition keys, если таблица грамотно разбита на партиции, и если они лежат на разных дисках. Запросы типа — посчитать мне среднюю цену по 5 миллиардам заказов, конечно, вас быстро положат на лопатки, просто из-за сумасшедшего IO.
— Диски. Оцените стоимость нормального SAN, посмотрите какие в MS SQL есть средства типа оракловского ASM (automatic storage manager).

Answer 4

[dbmaster]

согласен с pietrovich.

52500 милионов записей в год ~= 4375 в месяц ~= 145.83в день ~= 6.08 в час

добейтесь добавления 6 миллионов записей в час учитывая распределение по DATASOURCE_ID и будет вам счастье. В принцепи можно распределить разные data sources на разные сервера и таким образом добиться scale out.

Hint: Майкрософт даёт пробовать на пол года Enterprise версию — заказчику не обязательно платить сразу.

хотя вы же вроде ищите аргументы против (

Comments

[pietrovich]

но мне это категорически не нравится, то есть я почти уверен что MS SQL не потянет, но мне нужны доказательства

Я думаю поиск аргументов начат из-за уверенности что «не потянет». Да, у меня нет опыта работы с базами больше 1Tb на MS SQL Server 2008, но с не намного большими объемами возиться приходилось. а глядя на предполагаемую структуру данных предположить возможне сложности сложновато, скорее наоборот. Поэтому, чем искать альтернативы, проще взять десктопный двухтеррабайтник, триалку Windows Server, накатить на него триалку SQL Server не шибко навороченной редакции и попробовать. Посмотреть на данные, как они лягут на размер страницы, как хитрее накатить на это дело индексы (какие, fill factor, кластерные или нет), накорябать сторед котрый забьет винт под завязку тестовыми данными и попробовать подергать выборки на обычном десктопном железе. Эксперимент обойдется в стоимость винта и потраченных суток-двух, в зависимости от расторопности экспериментатора.
Более чем уверен, что при simple recovery mode и правильной разбивке таблицы на секции проблем не возникнет.
А если удачно пдобрать редакцию, то еще и сжатие можно будет использовать, благо вставки не шибко частые (у вас, кстати, ошибочка, речь шла о миллиардах а не миллионах, т.ч. 6-7K в час получается) а выборки затрагивают только отдельные и небольшие участки таблицы, т.ч. еще и на стореджах сэкономить можно.
Т.ч. заказчим, может, вовсе и не прав. SQL Server штука мощная, а раз заказчик хочет его, то скорее всего у него есть кому поручит присмотр за базой. В отличие от более экзотических решений, с сопровождением котрых потом еще можно хлопот поиметь.

[pietrovich]

З.Ы.: вообще, на таких структурах и выборках наверняка справится любая более менее серьезная СУБД. Наверняка можно и Postgress/Oracle приспособить, но я в их возможностях «плаваю», поэтому не знаю на сколько просто будет посечь таблицу на куски с возможным разнесением одной таблицы на несколько винтов. Все остльное элементарщина не достойная особого внимания — на такой структуре это будет выборка малых кусков из короткой таблицы, остальные данные лежат на винте невостребованные и кушать (кроме места) не просят.

[pietrovich]

И еще в помощь:
serverfault.com/questions/59460/oracle-vs-sql-server-to-handle-around-6-7-terabytes-of-data
msdn.microsoft.com/en-us/library/dd537533%28v=sql.100%29.aspx
msdn.microsoft.com/en-us/library/gg567302.aspx
msdn.microsoft.com/en-us/library/gg981694.aspx

[dbratus]

Вот я чего и боюсь, что узким местом станет сеть, connection pool, и т.д. То есть 6 млн. записей в час (т.е. 100 000 в минуту) на один физический сервер не пройдут. Шардинг — да, но это scale-out, а при том, что лицензия на каждую установку SQL Server стоит денег, это добавляет cost, помимо собственно железа. Поэтому именно для этой таблицы идея с SQL Server-ом мне не нравится.

Кроме того, обеспечить одновременно чтение и запись на одном сервере может оказаться невозможно. Нужно как-то отделять одно от другого. В MongoDB, например, мне нравится, что она может кешировать данные в памяти, занимая ее хоть всю. Это плюс.

В общем, разумнее всего — хранить обычные данные в обычной базе (MS SQL), а для данного случая копать распределенные базы.

[pietrovich]

Ай-яй. А я ведь тоже в порядкаж ошибся. Пересчитал, таки действительно речь о 6M вставок в час идет. Или 1.6k вставок в сек. Только что проверил на своем ноуте (core i7, hdd 5400RPM, раздел с данными забит почти под завязку, т.ч. фрагментация там недетская будет), вставка 100K строк со случайными данными в такую тублицу как у вас занимает до 40сек (включая генерацию этих данных), что составляет примерно 2.5K строк в секунду. Если я нигде не ошибаюсь, то даже мой ноут перекрывает потребности по вставкам более чем в полтора раза.
Если у вас приложение не будет на каждую строку открывать новое соединение, то с транспортом проблем возникнуть не должно даже если кидать по TCP.
П поводу отжора памяти — сколько инстансу выделите, столько он и захавает. И будет там и кеши хранить и всякие другие полезняшки.
В ашем случае достаточно просто посечь длинную таблицу на секции встроенными инструментами и горя знать не будете. Насекайте по таймштампу, выборки у вас котроткие, как максимум будут задевать две секции на границах, а в остальных случаях они всегда попадают в одну секцию, а значит общий размер таблицы вас смущать не должен.

Answer 5

[sl_bug]

Уместнее было бы рассказать про данные и как их будут использовать. Но в любом случае — шардинг.

Comments

[Григорий Перетяка]

Шардинг не в любом случае, все зависит от задачи. Я специально не касался этого в своем ответе, так как вариантов множество.

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

[sl_bug]

Имелась в виду задача — «Заказчик предлагает запихнуть это все в MS SQL 2008» и условия выборок самые ресурсоемкие.

Answer 6

[dbratus]

Структура данных такая:

DATASOURCE_ID: UUID
TIMESTAMP: DATETIME
VALUE: DOUBLE


Выборки по:

SELECT *
FROM DATA_TABLE
WHERE
DATASOURCE_ID = :ID AND
TIMESTAMP = (SELECT MAX(TIMESTAMP) FROM DATA_TABLE WHERE DATASOURCE_ID = :ID)


должны возвращать данные максимум за 1-2 секунды.

Comments

[sl_bug]

Или я туплю или ORDER BY TIMESTAMP LIMIT 1 (или как там в ms sql) был бы все таки быстрее :)

[sl_bug]

хотя если две записи с одинаковым id и timestamp то не прокатит…

[dbratus]

Не суть важно, это так, для примера.

[pietrovich]

У SQL Server 2008 весьма сносно реализован table partitioning (шардинг), если смотреть на ваши таблицы, то при правильной настройке секционирования проблем на таких объемах не будет вообще (если я правильно посчитал, то в выборку попадает порядка 3-5k строк). Только учтите, что на 2.7Tb данных, у вас индексы по объему могут столько-же занять. Хотя если воткнуть пару трешек в системник, то должно умещаться, разве что на «раскидать файлы по винтам» немного времени потратить придется. Есть, кстати, подозрение, что при таой структуре и таких выборках особых требований на RAM и проц не возникет, можно пробовать и на обычном офисном десктопе производительность потестировать.

[librarian]

Вы смеетесь? Под БД брать SATA? SAS+SSD под кэш.

[pietrovich]

А чем, конкретно под эту задачу, SATA не угодил?

Answer 7

[phasma]

Бери Oracle и не парься. Ну или DB2.

Comments

[pietrovich]

Oracle ту вряд-ли имеет существенное преимущество над SQL Server. Ну а DB2, как я понял из интернетов, существенно бы выиграл в производительности на более сложных запросах и структурах при частых вставках. А так…

[Zorkus]

Париться придется все равно и с ораклом тоже. Оракл хорош, когда грамотно настроен, а это дело долгое. И недаром хорошие ДБА стоят немало.

Answer 8

[Zorkus]

Вообще я бы сказал, если не говорить о ценах, а просто об объемах данных, вы еще далеко от того предела, когда реляционные базы не будут выдерживать вашей нагрузке, если конечно ваша модель данных именно реляционая. В полной стойке Exadata V2-8, например, почти 5 терабайт только Flash Cache Memory (и 100/330 теребайт основного хранилища, смотря по тому, поставите вы SCSI или SATA для него.)

Answer 9

[kmike]

При таких объемах и структуре данных может что-то вроде RRDtool исползовать, или whisper какой-нибудь?

Answer 10

[mike114]

В банках Teradata используют, легко переваривает огромные массивы информации

Answer 11

[iryndin]

Судя по запросу, вам нужно получить последние (по времени) данные по каждому датасорсу. Почему бы не брать периодически (раз в минуту, час, сутки) самый последний timestamp для каждого датасорса и не складывать его данные в другую табличку? И уже по этим (уменьшенным) данным делать ваш запрос. Соотв, объем данных уменьшится, т. е. ваш запрос будет выполняться быстрее. Первичные данные (raw дата) либо в шлак после n месяцев хранения, либо в файлы и на ленту, если они в дальнейшем могут понадобиться.

Answer 12

[InChaos]

MS SQL 2016 база 6.5Тб, рост базы 500 Гб/мес, новых записей 10-50 в секунду, чтение постоянно, в среднем 1500-2000 транзакций/сек
Оперативы 32 Гб, проц 8 ядер,
Сервер просто курит, в среднем 5-7% CPU, видел пики до 70% но редко, средний IO Wait - 30мс
Надо просто базу нормально проектировать зная какие нагрузки, какие операции будут выполнятся, а не как привыкли, создал табличку и все, а потом затык уже на 100 Гб ))))
Опять же запросы к базе нормально оптимизировать, индексы.