|
Top-level
 Про #кэширование #Memoize любопытно работает. По сути это здоровенная хэш-таблица с горячими и холодными значениями, при переполнении общего размера выделенного под неё память сперва вытесняются холодные (реже читаемые). А любопытен кейс, когда для очень горячего значени набор строк не влезает в эту память — его вытесняют, оставляя эту память для более холодных значений, потому что от части строк толку нет - остальные всё равно придётся с диска заново тянуть. 11 comments
Хотя, наверное, клокдрифтинг между ядрами жёстко что-нибудь ломает, если где-то есть завязки на физические (таймдельты в многопроцессных системах), а не логические (чисто X было раньше Y) часы. Хэш-таблицы с шириной строго являющейся степенью двойки - это довольно ловкий ход, позволяющий вместо остатка от деления (дорого) просто дёргать младшие N-битов хэша (дёшево). Индексы по enum-полям ещё наверняка обосраться насколько выгодная тема, они ж скорее всего в int4_ops сводятся вместо text_ops.  @strizhechenko о, и енум тоже надо повторить. а то "ну это же просто, как вы это не понимаете", но задачки почему то не решаются, а как прикручивать из объяснений непонятно совсем. @strizhechenko я про свою учёбу. что енум надо повторить. а то протыкал, но в голове вообще не отложилось. Чем мне нравится #postgresql - так это тем, что он имеет стандартизированные базовые блоки для операций над данными. Никаких велосипедов! А я их видел много и выгоды от этого кастома было мало (но иногда была, когда использовалась выверенная бенчмарками хэш-функция для специфической структуры данных для большого паттерн-матчинга с кучей доп. правил, которая при росте объёмов выигрывала у компилированной гигарегулярки/схожей реализации в постгре). |
Gregory's Server
Задумался, а как мне это всё в работе поможет и чот хз. Пока самое эффективное, что я делал, было избавление от insert ignore on conflict + update (разбивка по группам, почти равномерная по модулю от autoincrement integer id) всего что не заигнорилось, заменив это на вставку чанками по 1000 строк с чередованием этих групп и последующим выравниванием недавно вставленного с помощью хитрожопой математики. Благодаря этому получилось для 90% вставляемых строк создать всего одну версию строки, изначально, ещё при вставке выбрав им нужную группу. Дисковое I/O в итоге сократилось на 40% где-то, но помимо этого оно ещё и сгладилось (благодаря вставке чанками), а лаг репликации сократился без лишних апдейтов под той же транзакцией.
Всё это было бы не нужно, если бы все-все-все команды коллег взялись и организовали унифицированный экспорт данных с временными метками изменений, а все-все-все пользователи нашего сервиса писали бы SQL-запросы с учётом этих меток (CDC), чтобы не тянуть каждый раз много данных, и ещё все старые запущенные кампании поправили под это требование. Ух зажили бы.
Задумался, а как мне это всё в работе поможет и чот хз. Пока самое эффективное, что я делал, было избавление от insert ignore on conflict + update (разбивка по группам, почти равномерная по модулю от autoincrement integer id) всего что не заигнорилось, заменив это на вставку чанками по 1000 строк с чередованием этих групп и последующим выравниванием недавно вставленного с помощью хитрожопой математики. Благодаря этому получилось для 90% вставляемых строк создать всего одну версию строки, изначально,...