https://m.opennet.me/openforum/vsluhforumID3/135995.html Компания Citus Data, принадлежащая Microsoft, опубликовала распределённую СУБД Citus 13.0, реализованную в форме расширения к PostgreSQL 17. Citus обеспечивает горизонтальное масштабирование PostgreSQL в кластере на базе типового оборудования и позволяет разносить данные по узлам при помощи шардинга (sharding) с настройкой разделения на уровне столбцов и схемы хранения. Для приложений кластер Citus выглядит как один большой сервер PostgreSQL, объединяющий ресурсы образующих его узлов. Код написан на языке Си и распространяется под лицензией AGPLv3...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62701<br> https://m.opennet.me/openforum/vsluhforumID3/135995.html#72 Sun, 16 Feb 2025 10:23:15 GMT &gt; Высосано из пальца. Если это не тухлый mysql, то кластер хорошо живет, <br>&gt; ACID и очередь сообщений никто не отменял. <br><br>На распределеной системе ACID очень дорого стоит. На предприятиях практически никогда не случается, чтобы базы данных были независимы. Наоборот, они достаточно тесно связаны. Фактически, там одна база данных, пусть даже формально их там несколько. Поэтому чтобы сохранить согласованность (буква C из ACID) баз данных, распределенных по узлам, транзакция должна дождаться нормального возврата всех операторов от всех узлов, на котороых они выполнялись, чтобы зарегистрироваться. Ослабить согласованность (задержка согласованости) можно только для тех баз, которые, в основном, читаются и очень редко записываются. Если же поток операций записи сравним с потоком операций чтения, распределенная даже всего лишь на два хоста база теряет в производительности более, чем на порядок. И уже при сотне соединений запросы на чтение выполняются с лагом в секунды. А партия учит нас, что максимальная задержка, к https://m.opennet.me/openforum/vsluhforumID3/135995.html#71 Fri, 14 Feb 2025 14:48:45 GMT Вы пишете реальную чушь. Во первых MOEX использует протокол Plaza II, который можно быстро парсить и хранить как простое key-value, где key id транзакции. Во вторых все биржы закрываются несколько раз в день на клиринг. Поэтому ваши расчеты коней в сферическом вакууме ничего общего с реальным хранением данных не имеет, и кроме всего прочего биржы хранят данные с партицированием по дням. Если бы все было так просто, то биржы бы не закрывались на клиринг. Как писал ранее вы упретесь быстро в IOPS. Плюс запросы в РСУБД работают сложнее чем просто потоковая запись и чтение в примитивных субд, на практике довольно сложно предсказать скорость запросов.<br><br>&gt; Вы такой кластер замучаетесь обслуживать, а если один хост рухнет, вся система тут же остановится, потому что через некоторое время вы потеряете изоляцию баз данных, расположенных на разных хостах, друг от друга -- всегда есть и будут общие таблицы и, соответственно, трафик между узлами.<br><br>Высосано из пальца. Если это не тухлый mysql, то кластер хорошо живет, A https://m.opennet.me/openforum/vsluhforumID3/135995.html#70 Fri, 14 Feb 2025 10:23:52 GMT &gt; Вопрос не в дешевизне и надежности, вопрос в скорости запросов к бд. <br>&gt; На петабайтах данных, а вы их предлагаете, некоторые запросы у вас <br>&gt; могут даже за несколько дней не завершиться(Простой пример, построить отчет по <br>&gt; тратам клиента банка за несколько лет)<br><br>В начале 2010-х довелось работать в команде, которая сопровождала софт по инвестиционным портфелям для нескольких банков. Занимались, в том числе, и оптимизацией таблиц, имеющих отношение к транзакциям клиентов банка. Не знаю, о каких клиентах вы говорите, но мы моделировали записи клиента, осуществлявшего около сотни транзакций в сутки за 10 лет -- это где-то четыре сотни тысяч записей в таблице регистрации транзакций. Структура записи, насколько я ее помню, (id, client_id, value, date, credt_id, debet_id, flags, .._id, .._id, .._id). Хранимый индекс для курсоров (id+date). Все поля кроме date целые по 8 байт, date -- double (модифицированная юлианская дата, что астрономы используют). Три внешних ключа связаны с уже не помню с чем. Итого, 80 б https://m.opennet.me/openforum/vsluhforumID3/135995.html#69 Fri, 14 Feb 2025 09:20:57 GMT &gt; Проще и надежнее не лезть туда в чем не разбираетесь, не просто <br>&gt; так люди придумали должность DBA при наличии сисадмина. Базы данных это <br>&gt; не файловая помойка, а то некоторые так считают и относятся к <br>&gt; ним так.<br><br>А причем тут файловая помойка? Все базы данных сегодня работают поверх файловых систем -- прошли те времена, когда орацле и межделмаш напрямую с драйверами дисков работал мимо операционной системы (я застал это). Современые RDBMS и прочие nonSQL устанавливаются поверх файловой системы и им пофиг, вернее, они даже и не знают, на одном железном диске эта файловая система, поверх которой они работают, расположена или на тысяче -- файловая система для них делает просто внешнюю память нормального объема, куда они и устанавливаются. Соответственно, в любом случае на одной файловой системе размером в 480 Тбайт, подключенной по FC или IB, сервер орацле и даже постгрес, на системе с 128 ядрами будет обслуживать клиентов на порядок быстрее, чем 8 отдельных серверов каждый с 16 ядрами и 64 Тбайт внешн https://m.opennet.me/openforum/vsluhforumID3/135995.html#68 Thu, 13 Feb 2025 18:15:37 GMT Проще и надежнее не лезть туда в чем не разбираетесь, не просто так люди придумали должность DBA при наличии сисадмина. Базы данных это не файловая помойка, а то некоторые так считают и относятся к ним так.<br> https://m.opennet.me/openforum/vsluhforumID3/135995.html#67 Thu, 13 Feb 2025 18:11:43 GMT Вопрос не в дешевизне и надежности, вопрос в скорости запросов к бд. На петабайтах данных, а вы их предлагаете, некоторые запросы у вас могут даже за несколько дней не завершиться(Простой пример, построить отчет по тратам клиента банка за несколько лет), как раз дешевле иметь несколько дешевых серверов с nvme, чем один навороченный, и вы получите партицирование и меньший размер индексов на каждой ноде. Так же у вас может умереть райд контроллер к примеру, и похоронить вообще все, так что ваше решение не про надежность. Так же на вашем решении даже с nvme вы быстро упретесь в ограничение по IOPS, на большинстве решений вы в рейде nvme по iops уйдете не намного дальше чем единичный nvme диск, есть правда более дорогие решения, но там цена для некоторых может быть просто не подъемная.<br> https://m.opennet.me/openforum/vsluhforumID3/135995.html#66 Thu, 13 Feb 2025 09:47:43 GMT "Шардинг позволяет организовать хранение очень большого объёма данных, суммарный размер которых существенно превышает локальные накопители каждого из узлов кластера"<br>Проще, дешевле и надежнее купить хранилище на полтыщи терабайт с {InfiniBand&#124;FibreChannel} и воткнуть в шкаф с серваком.<br> https://m.opennet.me/openforum/vsluhforumID3/135995.html#65 Wed, 12 Feb 2025 23:43:00 GMT &gt; Это скорее проблемы вашего программного стека<br><br>о чём я и говорил выше:<br>&gt; не несут ответственности ни за продаваемое ими решение, ни за работу системы в целом<br><br>Нет, это не проблема моего стека, это проблема (а точнее комплекс проблем) конкретного незрелого пулера. А также архитектурная - наличие лишнего компонента, который не решает никаких проблем, но добаваляет багов, требует настройки и прочих приседаний с бубном. А ещё редко обновляется.<br><br>&gt; сами написали шардинг средствами приложения<br><br>Это говорит не только о переоценённых силах программистов, но и о качестве / компетенции техдира, который позволил им это сделать. <br><br>&gt; Чаще всего зрелось сторонних продуктов намного выше самописного<br><br>Самописные поделки - зло, тут я с Вами полностью согласен. Единственная между нами разница, что я считаю Odyssey поделкой :)<br><br>&gt; они ушли от самопального шардинга в сторону Citus<br><br>и правильно сделали <br><br>Написать пулер типа Odyssey на C - это хорошее упражение, правда, оно прокачивает знания протокола(-ов) постгреса, https://m.opennet.me/openforum/vsluhforumID3/135995.html#64 Wed, 12 Feb 2025 16:47:28 GMT даже отдельно Западная Римская империя просуществовала "недолго", всего четыреста лет.<br>А если считать от первых царей Рима до бесславного конца Константинополя - то "всего" два тысячелетия. Правда, то была - Цивилизация, и ее достижениями мы по сей день пользуемся.<br><br>Случай в 91м был крайне неслучаен, и в целом, даже после этого империя где была там и осталась, потеряв на время лишь небольшой процент своих территорий. <br><br>Но вот от нее останется потомкам только выжженная земля.<br><br><br>