сбор данных по-любому имеет смысл буферизовать, если не нравится хранилище на файловой системе - заведите простую таблицу без индексов и периодический процесс, который из неё будет читать и уже раскладывать всё как надо

а так вообще всё сильно зависит от паттернов доступа к данным
если всем 4000 одновременным клиентам надо работать одновременно со всеми 16TB - то дела плохи
но наверное не всё так плохо, и можно расшардить данные скажем по группам датчиков
заявленные объёмы нагрузки не кажутся запредельными, возможно что на нормальном серверном железе даже и шардить не потребуется

что касается отказоустойчивости - данные надо реплицировать

репликация в том виде, в котором она нормально работает на opensource базах данных - как правило асинхронная, и при падении мастера в момент отставания репликации на slave данные за время отставания могут потеряться
оцените эти риски, если пара минут данных может потеряться - может быть вам будет достаточно MySQL или Postrges, с master-slave репликацией и failover на slave

если нет - можно синхронно реплицировать данные, которые пишутся на диск, на уровне файловой системы (GFS, DRBD или же hardware-решение, какой-нибудь NetApp Filer)
не самое производительное решение, но зато всё очень надёжно - всегда есть физическая копия на соседнем сервере

AltCtrlDelzeehondсбор данных по-любому имеет смысл буферизовать, если не нравится хранилище на файловой системе - заведите простую таблицу без индексов и периодический процесс, который из неё будет читать и уже раскладывать всё как надо


Мне казалось, что если собирать за секунду со всех объектов то накопится 64-128К, такой размер в памяти уместится и приемлим для записи в базу. А записывать реже, ну можно, только тогда по запросам последних данных придётся отдавать часть из базы, часть из самодельного кэша, что гемор.
Баз со встроенным кэшем на запись+чтение, что не существует?


мм, ну просто каждая запись в таблицу - это апдейт её индексов
вы же сами говорите, там 2 большие таблицы, индексы тоже каждый раз перелопачиваете
если раз в несколько секунд собирать все данные и писать одной транзакцией несколько сотен новых записей, то можно убрать оверхед на запись индексов, по сравнению с более мелкозернистыми апдейтами

AltCtrlDelzeehondесли всем 4000 одновременным клиентам надо работать одновременно со всеми 16TB - то дела плохи

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


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


AltCtrlDelzeehondрепликация в том виде, в котором она нормально работает на opensource базах данных - как правило асинхронная, и при падении мастера в момент отставания репликации на slave данные за время отставания могут потеряться
оцените эти риски, если пара минут данных может потеряться - может быть вам будет достаточно MySQL или Postrges, с master-slave репликацией и failover на slave

Вот тут как раз я не разбираюсь, у какой базы с этим лучше? Потеря по всем объектам за пару минут очень не желательна.
Что дадут проприетарные СУБД в этом плане и какие?


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

проприетарная СУБД с синхронной репликацией - это оракл, и в данной конфигурации на нормальных железках обойдётся вам в пару сотен тысяч лицензионных долларов

AltCtrlDelzeehondесли нет - можно синхронно реплицировать данные, которые пишутся на диск, на уровне файловой системы (G
FS, DRBD или же hardware-решение, какой-нибудь NetApp Filer)

а тут вопрос с "горячей" заменой.

ну он как бы решается достаточно прямолинейно, elastic IP у сервера баз данных, и/или у файлового сервера

для mysql и postgres у нас есть отработанная конфигурация с репликацией файловой системы, 2 сервера с инфинибандом между ними, и с автоматическим failover-ом
то есть всегда все данные физически идентично пишутся не две отдельные машины и два рейда
файловер (переключение IP) в случае падения одной из машин на другую будет сделан в течение пары секунд

AltCtrlDelzeehondну то есть вам надо подумать, как отделить операционные данные от архивных так, чтобы клиент видел все данные, но при этом физически архив (он же не меняется) находился на отдельной железке
оракл умеет делать partitioning

проприетарная СУБД с синхронной репликацией - это оракл, и в данной конфигурации на нормальных железках обойдётся вам в пару сотен тысяч лицензионных долларов

Может я чего не понимаю, но два сервера (железо) по любому брать, хоть и для постгреса. А оракл
http://soft.softline.ru/oracle/oracle-database/
Enterprise Edition, лицензия на именованного пользователя - 29 269.50 руб
умножаем на 2.
http://soft.softline.ru/oracle/oracle-database-enterprise-edition-options/
Real Application Clusters - 14 172.60 руб.
Partitioning - 7 086.30 руб.

- совсем не пара сотен тысяч енотов.

Вполне возможно, что я не туда смотрю.


смотрите туда
вы неправильно понимаете словосочетание "именованный пользователь"
OracleВ трактовке Oracle, именованный пользователь — это лицо, уполномоченное использовать программы, установленные на одном или нескольких серверах, независимо от того, использует ли оно активно программу в какой-либо момент времени или нет. Автоматическое устройство (не требующее участия человека) при возможности доступа к программам считается именованным пользователем в дополнение ко всем лицам, уполномоченным использовать программы. При использовании аппаратных или программных мультиплексных средств число пользователей определяется на входе мультиплексора.

то есть вам нужно будет этих лицензий на 1000 датчиков + 4000 пользователей = 5000
что даёт совсем другие цифры на выходе

ну или берёте процессорную лицензию, на каждое из 8 или 12 ядер процессора

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

если эти логи на самом сервере, то потеряются вместе с ним. Собирать заново с объектов - теоретически можно, но узкие каналы, чистый самопал. Дороже выйти может.

мм, ну я же написал "где-то отдельно", на фронтальном сервере, принимающем запросы или LB
на отдельной сетевой файловой системе
короче неважно как, лишь бы отдельно от БД

DPH3
Еще можно, конечно, попробовать руками делать logshipping и DRBD, но тут могут быть подводные камни...

для репликации на уровне FS есть кстати ешё Lustre

репликации на уровне FSzeehondпропущено...


для репликации на уровне FS есть кстати ешё Lustre
Репликацию активно-меняющейся СУБД?

ну если она не меняется, или меняется редко - то какой смысл в её синхронной репликации?

в общем, если у ТС есть нормальный бюджет на железки, лучше делать репликацию аппаратно, на чём-то типа этого