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

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

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

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

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

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

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

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

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

Ну вообще говоря, 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).

согласен с pietrovich.

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

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

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

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

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

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

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 секунды.

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

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

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

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

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

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