VO
Кликхаус он про другое
Size: a a a
2021 July 05
VO
Собирать данные и делать по ним агрегации
MG
А что если я оставляю всё на MySQL как есть, а для инсертов делаю очередь на Редисе?
MG
не, наверное это тоже не выход
АГ
А почему бы не разделить всё на условное БД + Поисковик. Тогда поисковик будет реиндексироваться время от времени, а БД не будет так сильно страдать.
Можно настроить тот же сфинкс с дельта индексами, ну или самому ластик наполнять.
Можно настроить тот же сфинкс с дельта индексами, ну или самому ластик наполнять.
VO
я бы наверное вторую таблицу как-то переодически актуализировал бы, а поставшики менял бы свои индивидуальные таблицы.
АГ
Так тебе всё равно надо её наполнять. Теже вьюхи, надо будет преесобирать постоянно. При этом, у тебя мучаться будет вся таблица. А сфинкс или ластик можно наполнять только свежими обновлениями, тут и селекты проще будут
VO
не постоянно а раз в час например.
VO
но это уже надо смотреть по месту
АГ
Тут вопрос про актульность данных в "кеше". Всё равно пересбор материализованной вьюхи по большой таблице это не быстрый процесс
VO
т.е. абстрактная задача это одно, а когда вторая таблица -- это поставщики, то скорее всего апдейт будет только раз в сутки реально
VO
да похуй на актуальность, поставщик и так пиздит. склад у него совершенно не актуальный
AP
https://theweeklychallenge.org/blog/perl-weekly-challenge-120/?fbclid=IwAR2EY2bDmGq62oxMqqNq_ogUuAmmg-5kJW0K2QwjCEaAmVbegdCPKaZ1NUw
сходу моё решение первой задачи:
сходу моё решение первой задачи:
$ perl -E 'sub bit_flip { my $M = 0b01010101; (($_[0] >> 1) & $M ) | (($_[0] & $M) << 1) } sub test_flip { say "$_[0] => @{[bit_flip $_[0] ]}" } test_flip $_ for 101, 18'
101 => 154
18 => 33
MG
На самом деле с этим строго, если пару раз не актуально - бан. В остальном я полностью свободен - могу менять архитектуру как угодно.
АГ
Я бы задачу по поиску отдал другой утилите. Тот же sphinxsearch на базе mysql сделан, с ним можно общаться с помощью mysql драйвера перлового. При этом, ему надо дать запрос и он будет этим запросом наполнять себя сам. Просто индексацию надо по крону поставить.
Но если надо дельтаиндексы делать, то придётся чуток повозиться с ним.
Но если надо дельтаиндексы делать, то придётся чуток повозиться с ним.
AP
у тебя таблица товаров, таблица поставщиков и таблица связей поставщик-товар-цена, верно? третья таблица это два инта и один децимал. откуда там килобайты?
АГ
Таким образом у нас и с БД снимается нагрузки и поиск вполне себе гибкий может получиться
AP
не знаю размер децимал, но я обычно делаю типа 20,2 для денег, если биткоины не нужны. это 10 байт. два инта по 4. итого 18 байт на запись
AP
миллиард записей займёт 18 гб рам плюс индексы. дешёвого сервера на 128гб хватит
MG
таблицей поставщиков можно пренебречь, как и остальными, две главные таблицы - таблица товаров с указанием принадлежности к группе и таблица предложений поставщиков по каждому товару. Я не измерял размер записи точно, там несколько полей, включая описание товара на несколько байт, но допустим, всё поместится в память, получается ваше предложение - всё засунуть в память?