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

Нужно выбрать СУБД для высоконагруженной OLTP системы. Характер нагрузки - в основном update и select. Пользователей - около 5000. Объёмы порядка нескольких гигабайт. Может быть десятков гигабайт. Подключаться будут они не напрямую а через промежуточный слой, но тем не менее :) Дополнительное ограничение - цена. Первым делом рассматриваются бесплатные и урезанные версии платных субд :)


Полный список хотелок.

Возможность горячего бэкапа
Версионник.
Полноценные транзакции и ограничения целостности.
Возможность создания кластера
Возможности оптимизации хранения данных (partitioning, IOT и тп).
Способность работать с тысячей коннектов (shared server?)
Поддержка 64 разрядной ОС.

miksoft,

Логически одновременно. 5000 клиентов будут достаточно быстро долбить update-select-ы с некоторыми паузами между ними. Часть нагрузки мы наверное сможем снять промежуточным сервером.. Ну допустим порядка 300 update-ов в секунду.

Неточно выразился. Не 300 update-ов мы снимем, а 300 update-ов оставим :)

miksoftoltpmiksoft,

Логически одновременно. 5000 клиентов будут достаточно быстро долбить update-select-ы с некоторыми паузами между ними. Часть нагрузки мы наверное сможем снять промежуточным сервером.. Ну допустим порядка 300 update-ов в секунду.Именно update-ов?
Можно поподробнее о характере нагрузки? Терзают меня смутные сомнения, что правильно примененная буферизация может снизить требования на порядок-два.
Именно update-ов.
У 5000 датчиков есть параметры которые они меняют раз в секунду. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд. Решение напрашивается - раз в 10 секунд сбрасывать состояния в базу) Вот и получаем 500update/sec.
Если изменить update на инсерт последнего состояния, то через некоторое время быстро сделать select для определения последнего состояния будет невозможно, да и база вырастет :)

miksoftoltpУ 5000 датчиков есть параметры которые они меняют раз в секунду. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд. Решение напрашивается - раз в 10 секунд сбрасывать состояния в базу) Вот и получаем 500update/sec.Во-первых, получается 5000 update-ов в 10 секунд, что несколько не то же самое.
Согласен.
miksoftВо-вторых, у меня напрашивается другое решение. Раз в 10 секунд делать табличке truncate и грузить загрузчиком (а не INSERT-ами) туда данные. Думаю, в секунду уложитесь даже на десктопном железе. Надо подумать. Но на вскидку.. Делаем truncate и электричество выключается. ППЦ. Другие хинты вроде двух таблиц и переименований будут делать блокировку всех данных таблицы, пока переименование не закончиться. В эту таблицу могут писать и из неё могут читать и другие. Блочить всех раз в 10 секунд, пусть и на полсекунды.. в нашем случае это неприемлимо. Но мысль понятна, буду думать.

miksoftКстати, и как отсюда вытекают "Объёмы порядка нескольких гигабайт"? Или это какие-то другие объемы?
Это другие объёмы. Я описал отчего происходит основная нагрузка. Все остальные варианты использования вместе взятые генерят ещё примерно половину от этой нагрузки + большую часть данных.


Обсуждение снижения нагрузки, это конечно хорошо, но хотелось бы всё-таки вернуться к обсуждению субд. Что, в контексте моей проблемы, народ скажет про "основных игроков" postgresql и mysql ?

Yo.!обычно датчики пишут в файл, а уже из файла раз в какое-то время выгружают в БД, где уже анализируют данные ...
Это хитрые датчики :) Их показатели не для аналитики, а для реал таймового принятия решений используются.

Dimitry Sibiryakov
Senya_LАвтору треба
На его-то нагрузку? Не смешите мои подковы!

Требуется очень маленькое время отклика. Я готов партиционировать даже табличку в 1000 строк, если это поможет. А это может помочь :) Да и полный характер нагрузки я не знаю, постановка задачи ещё не закончена.

Yo.!oltp
Это хитрые датчики :) Их показатели не для аналитики, а для реал таймового принятия решений используются.
ну и нах тогда в базу что-то писать ? субд тут каким боком ? или масив на 5000 элементов в памяти у вас не помещается ??

Дубль два. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд.

miksoftoltpДелаем truncate и электричество выключается. ППЦ.Если "электричество выключается", то не все ли равно - не получат клиенты пустую табличку или они не получат данные с датчиков? Они же все равно ничего не получат...

Дубль три. Надо в базе всегда держать последнее состояние параметров, допустимо потерять не более 10 секунд.

oltpНеправильным проектированием загубить можно БД на любой СУБД.
MySQL хорош тем, что у него есть движок для хранения данных только в памяти. Т.е. загрузка данных может быть сведена вообще до миллисекунд. Но этот движок не транзакционен. Над in memory database я подумаю, спасибо за напоминание. Непонятно только , обеспечивает ли она сохранение данных при выключении электричества :) Если не обеспечивает - нужна ещё одна, для постоянных данных.

Всем: НЕ ЗАМОРАЧИВАЙТЕСЬ НА ДАТЧИКАХ . Кроме этого в БД есть ещё много всего. Не пытайтесь оптимизировать нагрузку, я создам соответствующий тред, если сам не справлюсь. Даже если убрать датчики нафиг, мои требования изложенные в первом посте всё ещё актуальны. Посоветуйте лучше что-нибудь по первому вопросу.

miksoft,

Аксиома :) Если система упадёт, упадёт она вся. Промежуточный слой тоже. Клиенты принудительно отключаются.

Требование - При включении после краша, данные в системе должны отставать не более чем на 10 секунд от предкрашевого состояния.

miksoftА про это вы ничего, кроме общих слов, не сказали. Потому что пока не могу, т.к. большая часть идей ещё в разработке.