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

а зачем вообще дропать индексы!?

допустим что для перестроения индекса, так как rebuild online не блокирующего запись нету

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

про эппл вроде шутили, если у нас нет каких-то функций, значит вам это не нужно)

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

например дефрагментация индексов

btree? это вроде у GIN с этим проблеммы

у btree

online дефрагментатор давно бы уже ктонить запилил :(

У btree в 9.4 тоже проблемы

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

это не значит что его нельзя сделать

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

надо просто сразу понимать СУБД не предназначина на постоянное изменении схемы. т.е. при всех плюшках postgres это всё же не самая штатная ситуация. Схема должна быть достаточно стабильна.

Угу, вы еще про бизнес то же самое скажите.

Угу, вы еще про бизнес то же самое скажите.

вы про что?

Про то, что все течет, меняется и развивается. Меняется бизнес -меняется софт. Меняется софт - меняются схемы в БД.

ну это то ясно, я говорю про то что бы это делать часто, к примеру несколько раз в день уже наверное часто особенно если крупная БД

Как раз для таких штук придумали jsonb

для того, чтобы все туда засунуть на случай изменений?

Да. Только засовывать надо не все, а по минимуму. То что меняется часто.

Так откуда мы можем знать, что поменяется завтра?

Что, и первичные ключи меняются? ;)

хорошо, делать таблицы из N + 1 столбцов, где N - количество столбцов в первичном ключе?

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

Как раз для таких штук придумали jsonb

вот сферический совет в вакууме

А вы пробовали все засунуть в jsonb ? тормозит?

Но если у вас действительно все действительно меняется действительно часто, то я вам не завидую. И код (всякие ORM/active record) тоже все переписываются ?

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

Потому что pgsql и в том числе документноориентированное хранилище тоже.

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

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

а зачем вы часто меняете схему в SQL?

Господи, да нет никакого часто

Просто есть сам факт того, что это время от времени происходит

да надумана проблема же

посоны, а как можно в pg вот этот запрос сделать? accounts = accounts.where('accounts.id = :search', { search: params[:search] }) оно ругается про то что не может текст к интегер привести

Потому что pgsql и в том числе документноориентированное хранилище тоже.

please stop

В общем это какой-то сферический спор. Для решения такой проблемы есть весь набор подходов - шардинг, партиционирование, jsonb, кеширование, абстракция и т.д.

Я так понял что jsonb вы смотрели и вам он просто не подошел :)

Привет всем, повторюсь

Как лучше хранить тайм-сериес? В самом бд

В пг том же

Как лучше хранить тайм-сериес? В самом бд

http://grisha.org/blog/2015/09/23/storing-time-series-in-postgresql-efficiently/ вот, может поможет

Как лучше хранить тайм-сериес? В самом бд

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

Если на таблице два одинаковых индекса, возможна ли ситуация, что планировщик будет иногда пользоваться второй копией, тем самым "балансируя" нагрузку / локи между ними?

Да, если порядок сортировки обратный

Это есть

Толку от этого есть, эсли вью агрегируют данные по разному

Только это помоему наблюдения :-)

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

Минимально год, 30 раз в секунду с одной точки, на одной точкео до 10 сенсоров

да надумана проблема же

как надумана, только что же с кейсом пришли, что индексы очень долго дропаются

Надо строить графики в реалтам и за последние сутки

Минимально год, 30 раз в секунду с одной точки, на одной точкео до 10 сенсоров

а а сколько точек ?

Пока 30

Пока 30

rdbms умрут, а отказоустойчивость нужна ?

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

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

фьюх... намучался. Мержил последний master с моей cmake веткой.

но оно опять работает

правда на MSVC надо ещё добить

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

хорошо, давайте на еще один круг. почему задача-то неверная?

Надо строить графики в реалтам и за последние сутки

А агрегация нужна ? т.е усреднение данных для уменьшения объема хранения

rdbms умрут, а отказоустойчивость нужна ?

Greenplum

Сотня нод

Ссд диски

Инфини бред

Бенд

Денег ведро :-)

А агрегация нужна ? т.е усреднение данных для уменьшения объема хранения

Да, например поминутная агрегация

Да

Greenplum

А забыл про него, тогда и эта от яндекса clickhouse еще

Не

Для этого не пойдёт

Клик хауз имеет специфику

Да, например поминутная агрегация

Еще как варианты это графитовые бекэнды, ceres, whisper, opentsdb (тащит хбейс)

Неважно

Важно сколько узлов

В плюме

Главное брать симметричное число

ну в тех условиях что выше сказали там пол ляма метрик в минуту, на 1м серве графита их можно записать, правда вот про 30 раз в секунду тут надо смотреть

Писать в хадуп

Читать в плюм по gphdfs

.пилить и считать

а сколько у него оверхед на точку в байтах ?

Hive медленный для этого

А какая разница, массово же грузится

Плюм это ведро денег,

Или два :-)

На железо

Ты скажи что надо спилить

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

Неа

Непойдет

Только железо

Амазон это боль

20 рядов железа :-)

Два петабайта

Полтера в секунду

Это да :-)

ну да такое выгодно на своем

Вариантов нет

Поверх хорошо положить рапид манер