Это разные вещи

А то бывает сдохнет два слева и мастер

Не разные, разные они пока под попой печка не стоит и греется

А то вариант один -вы там держитесь :-)

Не разные, разные они пока под попой печка не стоит и греется

Выкатил битый релиз в прод, дропнул часть данных и никакая реплика не поможет. Если только она не с latency

И, опять же, говоря про потерю данных из-за смены мастера без write concern = majority. Остальные базы тоже потеряют данные, только при этом ещё вручную (или скриптами) надо будет мастер переключать.

В релиз это да

Ну тогда расстрел за план отката

И тестовую среду

И 50 терр на одной тачке чтоли ?

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

а какая штука не закостенелая а вся из себя такая прогрессивная, с хипстерами и единорогами?

Клоны MySQL вполне себе не закостенелый. У них есть проблемы, практически нет реплики, но таки закостенелости там нет. Вон, у Марии там и реплика вроде поправленная (да я видел мнение Царева на тему правки реплики Марии). Но мы про закостенелость

В общем случае нельзя сказать что постгре закостенелая, ведь это, наверное, первая реляционная субд, которая ввела у себя поддержку работы json, то есть тут сработано очень инновационно.

В общем случае нельзя сказать что постгре закостенелая, ведь это, наверное, первая реляционная субд, которая ввела у себя поддержку работы json, то есть тут сработано очень инновационно.

Разве в Oracle не раньше появился json?

Возможно, не знаю точно. Ну тогда с поправкой - первая среди опенсорсных

Да и вообще фишек в нем не в пример семейсту mysql больше, как это можно называть закостенелостью? Просто отсутствие концентрации на теме репликации.

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

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

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

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

вы небось еще и python балуетесь?

эмм...ну это уж вы точно перегнули. Просьба не утраивать холивар. Если критиковать то конкретно.

И уж точно не нужно рассказывать про замечательный mysql. Далеко не все так радужно в датском королевстве.

вы небось еще и python балуетесь?

Я не разделяю набросов на postgres, но с Python-то что не так?

вы небось еще и python балуетесь?

паливо. и Го

уважаемые коллеги, давайте не будем чат превращать в разборки кто круче. Мне кажется он не для этого создавался Олегом.

с любителями python что-то не так (в большинстве имхо) в почти любом чате найдется мажорчик который заявляет морща носик "все что не python - фи-фи-фи..." смотрю и сдесь этот тон "фи-фи-фи..."

И уж точно не нужно рассказывать про замечательный mysql. Далеко не все так радужно в датском королевстве.

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

эмм...ну это уж вы точно перегнули. Просьба не утраивать холивар. Если критиковать то конкретно.

да это уже какойто там десятый цикл за много лет. а воз даже глаз не открыл ) чо уж

Повторюсь, это чат о PostgreSQL. Давайте не будем устраивать очередной холивар. Заранее спасибо :)

?

Не холивара ради, а абсолютно реальный кейс. Вот нам нужно хранить метаданные про файлы. Файлов - порядка 500млн. Есть с десяток общих полей - размер, несколько типов хэшей, даты, magictype, ну и подобное. При это есть еще несколько десятков полей, которые присутствуют только у некоторого множества этих записей. Причем, они появляются хаотично - нельзя заранее предположить весь набор метаданных, который будет у файла. Плюс, жизнь меняется и периодически мы начинаем добавлять еще какие-то метаданные, но только к новым записям - старые остаются со старым набором (но если попадут в обработку, то будут обновлены с новыми полями). По части полей, конечно, есть индексы. Из этой кучи нужно периодически выбирать записи с различными наборами значений полей. Сейчас эта бд - на монге. Отсутствие схемы, sparse индексы позволяют относительно без боли решать задачу на двух средних серверах. Как такая задача могла бы лечь в постгрес? Особенно интересны моменты с разнообразными наборами полей и разряженными индексами.

Думаю JSONB вам бы помог

Я конечно читал про jsonb, но у меня ощущение , что он еще сырой. И вот тут даже мелькало, что вроде постгрес не умеет в нем уникальные индексы - это тоже печаль

Надеялся, что кто-нибудь расскажет про jsonb на последнем pgdays в питере, но что-то никто не обмолвился. =(

Если сырость беспокоит, тогда hstore

Меня больше всего убивает адовый синтаксис для JSONB.

Это не то, к чему меня жизнь готовила

Молю о пощаде, как разработчик!

помоему по jsonb нельзя построить частичный индекс по значению ?

или я ошибаюсь ?

Если сырость беспокоит, тогда hstore

я б тут кассандру взял )

я б тут кассандру взял )

Из пушки по воробьям?)

Если сырость беспокоит, тогда hstore

Простите, но мне нужно нечто большее, чем хэштаблица ...

Тогда забить и юзать кошерный jsonb

Коллеги, речь про постгрес, давайте не уходить в оффтопики. Как решить такую задачу на нем, гипотетически?

Из пушки по воробьям?)

ну хз если там старт на 500м записях, и будут новые. Возьму что то, что легком масштабируется из коробки )

Ну так и решать, 10 постоянных полей кладем в схему, остальное в json/hstore. Дальше экспериментируем с индексами.

Да, конечно, функционал JSONB в PostgreSQL не такой большой как в документоориентированных БД. Поэтому попробую привести цитату из документации. Не нужно думать что JSON в слоне это замена NoSQL

Представлять данные в JSON можно гораздо более гибко, чем в традиционной реляционной модели данных, что очень привлекательно там, где нет жёстких условий. И оба этих подхода вполне могут сосуществовать и дополнять друг друга в одном приложении. Однако, даже для приложений, которым нужна максимальная гибкость, рекомендуется, чтобы документы JSON имели некоторую фиксированную структуру. Эта структура обычно не навязывается жёстко (хотя можно декларативно диктовать некоторые бизнес-правила), но когда она предсказуема, становится гораздо проще писать запросы, которые извлекают полезные данные из набора "документов" (информации) в таблице. Данные JSON, как и данные любых других типов, хранящиеся в таблицах, находятся под контролем механизма параллельного доступа. Хотя хранить большие документы вполне возможно, не забывайте, что при любом изменении устанавливается блокировка всей строки (на уровне строки). Поэтому для оптимизации блокировок транзакций, изменяющих данные, стоит ограничить размер документов JSON разумными пределами. В идеале каждый документ JSON должен собой представлять атомарный информационный блок, который, согласно бизнес-логике, нельзя разделить на меньшие, индивидуально изменяемые блоки.

напоминаю, по "непостоянным" полям тоже нужны индексы

по непостоянным вы можете только создать GIN на весь JSON. Но там будет только проверка на равенство

по непостоянным вы можете только создать GIN на весь JSON. Но там будет только проверка на равенство

интересно. Но проверки на равенство маловато, есть даты и интересны >< . Хотя худо-бедно уже наверное можно выкрутиться...

Я вот только подозреваю, что GIN индекс будет огромный

Да, вы правы. Индекс будет большой

На 500+М это проблема =(

А метаданные прям бесконечно добавляются и добавляются?

Т.е. количество разных столбцов растет? Всегда новые ключи?

Угу. 100-500 тыс за сутки примерно только новых, + обновление старых

Я имею в виду столбцы а не строки

Нет, кол-во "столбцов" растет не постоянно

Можно по мере появления новых создавать под них колонки в бд

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

для уменьшения идекса можно вопспользоваться классом операторов jsonb_path_ops

Новые колонки на 500M записей?

Да вроде должно быстро работать. Или это я путаю с concurrent index?

Если вы про "в лоб", т.е alter table, то это.. м, очень долго =)

Новые колонки на 500M записей?

Nullable быстро сделается же

Хотя, может я отстал от жизни и в последних версиях есть некая магия?

нет, магии нет. проблем можно избежать только если вы добавили пустой столбец.

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

Спасибо. Завтра попробую уточнить, где там с модификацией таблицы были подводные камни =) Создавать колонки руками по мере надобности - в общем-то может и сработать. Поддерживать код посложнее, но уже похоже на вариант =)

ну хз если там старт на 500м записях, и будут новые. Возьму что то, что легком масштабируется из коробки )

Нет, ты не прав! Надо купить сервер где будет 128 CPU и пол-террабайта оперативки, ведь все ресурсы убухиваются, чтобы постгрес отлично масштабировался вертикально. Но проблемы нищих веб-девелоперов никого не интересуют :)

Офтопик, но масштабировать монгу из коробки тоже не крем-броюле. Шардинг данных напополам - это по нормальному нужно 4 сервера примерно одинаковой мощности - 2 шарды и каждая - в репликасете. Ну вот мои 2 сервака под монгу сейчас стоят порядка 500-600тыс руб. Вот так просто потратить 1млн на шардинг - это тоже не для бедных веб девелоперов =)

Да, и не забываем, что +1 шарда = +2 сервера, ибо должны быть в реплике...

Да, и не забываем, что +1 шарда = +2 сервера, ибо должны быть в реплике...

Шард можно и не из реплик делать, в принципе. Если за данные не страшно)

Ну можно , да =) И бэкапы не делать, заодно уж =)

Ну просто это не проблема монги, в любой другой базе тоже надо минимум мастер-слейв желать на каждый шард

Арбитр лёгкий и его можно хоть на виртуалке поднять. Конфиг сервера тоже можно совместить.

Да ну я ж не говорю, что она виновата. Я просто замечаю, что шардинг в монге - не магия.

Про арбитра речи не идет, с ним всё понятно.

Просто если у вас отвалится шарда и она не в реплике - вы встряли.

И я уже не буду вспоминать про репликацию в монге - это тоже отдельная песня, но будет уже совсем оффтопик

Тут есть отдельная группа по монге, можно там)

Я уже там =)

Тут есть отдельная группа по монге, можно там)

Ссылочку можно?

MongoDB Russian https://telegram.me/MongoDBRussian

Но там достаточно тихо обычно

Вобщем я тут померял немного

alter table test add column f16 varchar(512); ALTER TABLE Time: 1006.393 ms

На таблице из 111млн. записей, 15 колонок, без нагрузки.

Если параллельно запустить запрос insert into ... select from на пару миллионов строк, то создание колонки сильно замедляется.

Хотя не, вру, там запрос на вставку не пару миллионов а 27 миллионов строк.

Вроде alter table требует эксклюзивного лока таблицы. О каких запросах речь?

Да но в случае если мы добавляем колонку с null значением по дефолту, то лок краткосрочный :)

Угу. 100-500 тыс за сутки примерно только новых, + обновление старых

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

Ну не полностью всё ок, но в целом работает. Особо активно обновляющиеся данные (до 1000 апдейтов в секунду) таки приходится выносить в отдельные базы (тоже монга на том же сервере, но документов меньше). Чудес не бывает, 128гигов памяти не хватает чтобы и индексы держать и данные кэшить.

простите, или вы про постгрес? :) Монга тянет. С постгресом пока только смутно ясно как это можно было бы организовать.

Да, я про постгрес. Мне кажется, тут вариант - поставить параллельно новый сервер с постгресом, и запросы с продакшена дублировать на него также. И можно измерять разные метрики.