Comments 9
А у Яндекса несколько своих СУБД? Просто, насколько я понял, для облаков используется СУБД на базе PostgreSQL и у Яндекса, вроде-как, такая концепция, что они все свои доработки коммитят только в общий репозиторий PostgreSQL и это гарантирует, что их СУБД совместима с базовым PostgreSQL.
Если сократить эту простыню текста в нормальный вид то имеем следующее.
Есть сервер СУБД и как на него навесить кучу кеширующих серверов которые могли бы отвечать на запросы самостоятельно. При этом придумываем механизм что бы сервера кешей могли саморазмножаться или самоуничтожаться. Попутно решаем геморой синхронизации данных кешей и центральной СУБД
Деление аналитических запросов и транзакционных. Аналитический запрос подразумевает запрос к столбцам без индексов - там идёт полный скан столбца. Транзакционный подразумевает что он заранее оптимизирован и использует индексы везде где можно для быстрого выполнения.
Также упомянуты такие костыли как например что делать при удалении строк? Posgres например не удаляет их, а помечает как удалённые, или при обновлении строки тоже создаёт новую копию. При этом страницы обрастают кучей незадействованной памятью - которую нужно потом уничтожать сборщиком мусора. В противовес этому есть алгоритмы автоматической ликвидации таких пустых мест налету. Но каждый подход имеет свои плюсы и минусы.
Упомянуты векторные вычисления. Это ассемблерные инструкции процессора Sse2, Avx2. Что это? Инструкции позволяющие атомарно читать, записывать, сравнивать данные длиной 16,32,64,128,256 и более байт. Это сильно ускоряет скорость например поиска по колонке с таким типом данных - а также решает геморрой с параллельной записью и чтением, когда происходит гонка потоков чтения и записи. И чтение происходит битым (половина данных старая, половина новая и вариации). Но для работы векторных инструкций данные должны быть выровнены в памяти. т.е адреса должны быть кратны тем самым числам 16,32,64,128,256. Иначе работать не будет - ограничения железа процессора. Нормально данные выровнять в памяти можно в СУБД колоночного вида. Postgres же имеет строчный вид - и данные там не выровняешь. Когда у тебя все типы идут друг за другом. Можно конечно кучу дыр на выравнивание наставлять - но это дикий оверхед по памяти.
Дальше насколько понял из статьи - анализируется запрос. Если жирный содержит кучу запросов к столбцам без индекса - то отправляем на кеширующий сервер с жирной памятью. Ведь для выполнения запроса нам нужно будет перелопатить весь столбец. Это значит выгрузить его в память с диска. Если не жирный можно отправить на дохлый кеширующий сервер. В продвинутых системах есть выгрузка неиспользуемых страниц автоматом.
Вывод. Очень туманно (специально?) и запутанно описали принцип построения кеширующих серверов. Анализа на ходу типа запроса(например есть ли запрос к перебору столбца без индекса) и распределения его на жирные/тощие кеши. Также навели туману на разницу типов построения базы данных колоночной и строковой.
YDB под Windows Server?
Почему сложно разработать OLAP-базу данных, если у тебя уже есть OLTP