почему find за O(N) написано?)

хз, думал там бинари серч и будет логарифм

но ты почитай

может там уровни учли

но ты можешь пглоадером поставить в мускуль перекладываться на выхи

сам всё проверишь

сейчас погуглю на счёт time complexity поподробнее

https://www.slideshare.net/matsunobu/myrocks-deep-dive йошинори почитай еще

или погугли видос еще

заодно про блумфильтр узнаешь гг

спасибо!

судя по этой штуке просадка по чтению где-то в три раза

ну значит не O(N) и то хорошо

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

https://github.com/wiredtiger/wiredtiger/wiki/Btree-vs-LSM вот собственно

wiredtiger тоже кстати классные ребята делают

ага)

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

ты на джине вообще охуеешь скорее всего

я вообще не знаю почему там фастапдейт включен подефолту

:)

хм, а REFRESH MATERIALIZED VIEW CONCURRENTLY удаляет индекс старый сразу же?

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

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

хм, а REFRESH MATERIALIZED VIEW CONCURRENTLY удаляет индекс старый сразу же?

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

А как он переходит от старого состояния к новому?

магия mvcc каталога

звучит как будто то что нужно

ну это лучше чем копировать табличку, менять местами, вот это всё

но это такое решение которое я не рассматриваю впринципе

почему? если родительскую хранить без индексов и туда вставлять новые пачки потом обновлять вью если в этот момент правда доступны старые индексы — это же круто

при условии, что вью не займет места более чем в ≈2 раза больше чем родительская (не учитывая индексы)

потому что места x2 и индексы строить долго и дорого

ах да, с рефрешом уже x3

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

но это пока что

"копирование таблички" занимает х2 :(

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

что значит ничего нельзя сделать? select можно же?

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

важен только select остальных операций юзер не вызывает самостоятельно

ты не учитываешь загрузку диска. вымывание кеша

возможно ты реально экономишь там, где не надо

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

я серьезно

всё катится в сторону myrocks?)

возможно это будет стоить дороже семи серверов

во-первых на майрокс я бы посмотрел очень внимательно, пока у тебя пок и выхи, это бесплатно

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

ну вот я пытаюсь добиться того чтобы он не вис) то что данные не актуальны это не страшно

если оно совсем остановится и не ночью — будет правда дорого стоить

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

если только ночь не будет удлиняться

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

она ещё якобы мало весит аля кликхаус

попробуй кассандру

ну нет, кликхаус жмет колоночки, тут никакие строковые не обгонят

не понял

я про "она ещё якобы мало весит аля кликхаус"

ааааа ну ок

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

грустно когда сервер один ?

а что там такого приятного в кассандре с индексами для такой задачи?

ничего

еще и тормозить будет

допустим через два месяца дадут второй, но это не точно?

еще и тормозить будет

ок

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

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

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

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

ну и да все это шардировано

слишком сложно :(

без PK lsm не работают, заводи сиквенс если лень но скорее всего у тебя batch id + entity найдется

кстати, чото я не вижу https://github.com/facebook/mysql-5.6/wiki/MyRocks-limitations требования

еще думаю все-таки над тем чтобы сделать две таблички: первая со старыми данными вторая горячая куда лить новые пачки если вторая привысит например 40млн, то залить её в основную, а отсюда эти данные очистить бред?)

кстати, чото я не вижу https://github.com/facebook/mysql-5.6/wiki/MyRocks-limitations требования

чего именно?

чего именно?

требования пк

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

еще думаю все-таки над тем чтобы сделать две таблички: первая со старыми данными вторая горячая куда лить новые пачки если вторая привысит например 40млн, то залить её в основную, а отсюда эти данные очистить бред?)

так мы посмотрим за сколько времени батч переливается

только один хрен вставка что туда что туда времени занимает почти одинаково

логарифм там 30 против 25

прирост будет в скорости 20% :(

вопрос: в транзакцию постгреса умещаются 40млн строк?)

и пока транзакция не commit, индексы же не перестраиваются?

на коммит - уже все перестроено

а, бред, толку не шибко

на коммит - уже все перестроено

как тогда откат работает?

mvcc

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

поясни

ну допустим

допустим ты нажал коммит после инсерта и только тогда вставляются данные в индексы?

в транзакции: 1. удалить индексы 2. залить 40млн 3. построить индексы 4. commit

сможет ли до commit юзер использовать предыдущий индекс?

я не понимаю почему ты не понимаешь что перестраивать индексы это бред

ты не учитываешь загрузку диска. вымывание кеша

я помню

вопрос скорее к понимаю mvcc был

а, так зайди проверь из двух сессий

я не понимаю почему ты не понимаешь что перестраивать индексы это бред

кстати в доке постгреса такой метод в частности описан при bulk insert

ну вот я нажал в одной сессии postgres=# drop index test_v_idx; DROP INDEX во второй postgres=# explain analyze select * from test where v = 1; ждет