История изменений

А тогда запись на диск в MySQL/PostgreSQL/SQLite оказывается бесполезной обузой, и вообще добрая половина их фич не нужна.

Это только потому, что сейчас RAM столько, сколько раньше дисков не было. На моем настольном компе 128GB RAM и 16 ядер. Еще лет 10 назад это был очень хорошего уровня сервер (особенно по части CPU). OLTP DB, если в них не пихают чего не надо и чистят вовремя, будут небольшие. И даже 100GB — это уже для них много. Это аналитические и гибридные БД могут до петабайтов разрастаться.

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

Но если говорить про современное железо (2020+), то оно уже по скорости сопоставимо с RAM. Мой Samsung 970 Pro уверенно держит в районе 200К 4K IOPS в устоявшемся режиме QD32. Это где-то 900MB/s, и это уже дохрена. Ты пойди еще такой поток обработай. А в свою настольную тачку я могу вставить 7 таких.

Опять же, появляется NVRAM, который тоже можно добавлять в иерархию памяти. Со временем, он придет в кэши консумерских SSD-шек, так что ситуация с дюрабельной записью улучшится.

Т.е. если делать архитектуру сразу для всей современной иерархии памяти, а не для одной только RAM или HDD, то можно много чего достичь. Но, разумеется, будет много хардкорного программирования.

Как я уже выше говорил, «100-миллионные» числа пиковых RQ/s, которые можно получить на RAM и хэш-таблицах сильно упадут и из-за необходимости поддерживать конкурентные обновления, и из-за транзакционной семантики, и из-за самих структур данных. Динамические структуры данных строятся на деревьях, а там сразу скорость в разы меньше, чем у хэш-мэпа, и это как минимум. Т.е. пиковые числа — это хорошо, но что будет для конкретной задачи? Сейчас появляется новый класс вычислительно-интенсивных задач — ИИ — и там свои нюансы. Если над динамическими данными нужно гонять аналитику, то нужен как минимум SI, причем чтобы читатели не мешали писателям.

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

Валидный поинт, я его полностью разделяю. Я сам с этим столкнулся, и в итоге написал себе Меморию — фреймворк для разработки движков хранения и обработки данных для современного железа (на основе эффективных реконфигурируемых персистентных структур данных).

В отличие от меня, разработчики того же Pg вынуждены писать на С, так как из-за своего механизма исключений не могут плавно перейти на С++, и вынуждены тянуть совместимость со старыми задачами. Эта клиент-серверная архитектура разрабатывалась 40+ лет назад под жесткие диски. И потом её костыляли и костыляли, и костыляли. У него есть, разумеется, своя ниша и надолго. Но к современным иерархиям памяти он не приспособлен просто на уровне архитектуры. (Я так еще понимаю, что они не хотят напарываться на патентные мины, но это уже другая история)

— при ослаблении требований согласованности получилась даже не «согласованность в конечном счёте/eventual consistency», а вообще хрен знает что, где периодически пользовательские данные растворяются в небытии, вплоть до целых исчезающих вникуда таблиц.

А я всем говорю: «Ребята, EC — это, на самом деле, очень сложно. То, что у вас тут — это не EC.» RDBMS консистентность ослаблять не умеют. Они умеют ослаблять изоляцию, и только так, как в стандарте.

Понимаешь, почему я такой распальцованный и оптимистичный? У меня под 100%-ным контролем strictly serializable реконфигурируемый мультимодельный движок с конфигурируемой приложением дурабельностью. Я могу сам в нем допрограммировать то, что надо, если надо и когда надо. Необходимая гибкость предусматривается изначально дизайном фреймворка и продвинутыми техниками С++ (метапрограммирование). Дай мне железку, и я под неё сконфигурирую data layer, оптимально её утрилизирующий.

Тогда как если ты возьмешь тот же PG, то у тебя на руках черный ящик с древней архитектурой для позапрошлого поколения железа, который хрен научишь тому, что тебе надо. Вот если бы PG «открылся бы», стал бы фреймворком, из компонентов которого можно было бы собирать свои СУБД под свои нагрузки, то это была бы другая история. Они там, хотя бы, storage смогли от процессинга абстрагировать уже?

Т.е. вот если вернуться к твоему вопросу из шапки про продвинутые техники. Вот у меня есть площадка для реализации продвинутых техник программирования на С++ для выжимания из вновь появляющихся вычислительных архитектур по-максимуму. От функциональщины там ФСД/ПСД, но не для RAM только, а для более разнообразной иерархии памяти.

А тогда запись на диск в MySQL/PostgreSQL/SQLite оказывается бесполезной обузой, и вообще добрая половина их фич не нужна.

Это только потому, что сейчас RAM столько, сколько раньше дисков не было. На моем настольном компе 128GB RAM и 16 ядер. Еще лет 10 назад это был очень хорошего уровня сервер (особенно по части CPU). OLTP DB, если в них не пихают чего не надо и чистят вовремя, будут небольшие. И даже 100GB — это уже для них много. Это аналитические и гибридные БД могут до петабайтов разрастаться.

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

Но если говорить про современное железо (2020+), то оно уже по скорости сопоставимо с RAM. Мой Samsung 970 Pro уверенно держит в районе 200К 4K IOPS в устоявшемся режиме QD32. Это где-то 900MB/s, и это уже дохрена. Ты пойди еще такой поток обработай. А в свою настольную тачку я могу вставить 7 таких.

Опять же, появляется NVRAM, который тоже можно добавлять в иерархию памяти. Со временем, он придет в кэши консумерских SSD-шек, так что ситуация с дюрабельной записью улучшится.

Т.е. если делать архитектуру сразу для всей современной иерархии памяти, а не для одной только RAM или HDD, то можно много чего достичь. Но, разумеется, будет много хардкорного программирования.

Как я уже выше говорил, «100-миллионные» числа пиковых RQ/s, которые можно получить на RAM и хэш-таблицах сильно упадут и из-за необходимости поддерживать конкурентные обновления, и из-за транзакционной семантики, и из-за самих структур данных. Динамические структуры данных строятся на деревьях, а там сразу скорость в разы меньше, чем у хэш-мэпа, и это как минимум. Т.е. пиковые числа — это хорошо, но что будет для конкретной задачи? Сейчас появляется новый класс вычислительно-интенсивных задач — ИИ — и там свои нюансы. Если над динамическими данными нужно гонять аналитику, то нужен как минимум SI, причем чтобы читатели не мешали писателям.

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

Валидный поинт, я его полностью разделяю. Я сам с этим столкнулся, и в итоге написал себе Меморию — фреймворк для разработки движков хранения и обработки данных для современного железа (на основе эффективных реконфигурируемых персистентных структур данных).

В отличие от меня, разработчики того же Pg вынуждены писать на С, так как из-за своего механизма исключений не могут плавно перейти на С++, и вынуждены тянуть совместимость со старыми задачами. Эта клиент-серверная архитектура разрабатывалась 40+ лет назад под жесткие диски. И потом её костыляли и костыляли, и костыляли. У него есть, разумеется, своя ниша и надолго. Но к современным иерархиям памяти он не приспособлен просто на уровне архитектуры. (Я так еще понимаю, что они не хотят напарываться на патентные мины, но это уже другая история)

— при ослаблении требований согласованности получилась даже не «согласованность в конечном счёте/eventual consistency», а вообще хрен знает что, где периодически пользовательские данные растворяются в небытии, вплоть до целых исчезающих вникуда таблиц.

А я всем говорю: «Ребята, EC — это, на самом деле, очень сложно. То, что у вас тут — это не EC.» RDBMS консистентность ослаблять не умеют. Они умеют ослаблять изоляцию, и только так, как в стандарте.

Понимаешь, почему я такой распальцованный и оптимистичный? У меня под 100%-ным контролем strictly serializable реконфигурируемый мультимодельный движок с конфигурируемой приложением дурабельностью. Я могу сам в нем допрограммировать то, что надо, если надо и когда надо. Необходимая гибкость предусматривается изначально дизайном фреймворка и продвинутыми техниками С++ (метапрограммирование). Дай мне железку, и я под неё сконфигурирую data layer, оптимально её утрилизирующий.

Тогда как если ты возьмешь тот же PG, то у тебя на руках черный ящик с древней архитектурой для позапрошлого поколения железа, который хрен научишь тому, что тебе надо. Вот если бы PG «открылся бы», стал бы фреймворком, из компонентов которого можно было бы собирать свои СУБД под свои нагрузки, то это была бы другая история. Они там, хотя бы, storage смогли от процессинга абстрагировать уже?

А тогда запись на диск в MySQL/PostgreSQL/SQLite оказывается бесполезной обузой, и вообще добрая половина их фич не нужна.

Это только потому, что сейчас RAM столько, сколько раньше дисков не было. На моем настольном компе 128GB RAM и 16 ядер. Еще лет 10 назад это был очень хорошего уровня сервер (особенно по части CPU). OLTP DB, если в них не пихают чего не надо и чистят вовремя, будут небольшие. И даже 100GB — это уже для них много. Это аналитические и гибридные БД могут до петабайтов разрастаться.

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

Но если говорить про современное железо (2020+), то оно уже по скорости сопоставимо с RAM. Мой Samsung 970 Pro уверенно держит в районе 200К 4K IOPS в устоявшемся режиме QD32. Это где-то 900MB/s, и это уже дохрена. Ты пойди еще такой поток обработай. А в свою настольную тачку я могу вставить 7 таких.

Опять же, появляется NVRAM, который тоже можно добавлять в иерархию памяти. Со временем, он придет в кэши консумерских SSD-шек, так что ситуация с дюрабельной записью улучшится.

Т.е. если делать архитектуру сразу для всей современной иерархии памяти, а не для одной только RAM или HDD, то можно много чего достичь. Но, разумеется, будет много хардкорного программирования.

Как я уже выше говорил, «100-миллионные» числа пиковых RQ/s, которые можно получить на RAM и хэш-таблицах сильно упадут и из-за необходимости поддерживать конкурентные обновления, и из-за транзакционной семантики, и из-за самих структур данных. Динамические структуры данных строятся на деревьях, а там сразу скорость в разы меньше, чем у хэш-мэпа, и это как минимум. Т.е. пиковые числа — это хорошо, но что будет для конкретной задачи? Сейчас появляется новый класс вычислительно-интенсивных задач — ИИ — и там свои нюансы. Если над динамическими данными нужно гонять аналитику, то нужен как минимум SI, причем чтобы читатели не мешали писателям.

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

Валидный поинт, я его полностью разделяю. Я сам с этим столкнулся, и в итоге написал себе Меморию — фреймворк для разработки движков хранения и обработки данных для современного железа (на основе эффективных реконфигурируемых персистентных структур данных).

В отличие от меня, разработчики того же Pg вынуждены писать на С, так как из-за своего механизма исключений не могут плавно перейти на С++, и вынуждены тянуть совместимость со старыми задачами. Эта клиент-серверная архитектура разрабатывалась 40+ лет назад под жесткие диски. И потом её костыляли и костыляли, и костыляли. У него есть, разумеется, своя ниша и надолго. Но к современным иерархиям памяти он не приспособлен просто на уровне архитектуры. (Я так еще понимаю, что они не хотят напарываться на патентные мины, но это уже другая история)

— при ослаблении требований согласованности получилась даже не «согласованность в конечном счёте/eventual consistency», а вообще хрен знает что, где периодически пользовательские данные растворяются в небытии, вплоть до целых исчезающих вникуда таблиц.

А я всем говорю: «Ребята, EC — это, на самом деле, очень сложно. То, что у вас тут — это не EC.» RDBMS консистентность ослаблять не умеют. Они умеют ослаблять изоляцию, и только так, как в стандарте.

Понимаешь, почему я такой распальцованный и оптимистичный? У меня под 100%-ным контролем strictly serializable реконфигурируемый мультимодельный движок с конфигурируемой приложением дурабельностью. Я могу сам в нем допрограммировать то, что надо, если надо и когда надо. Необходимая гибкость предусматривается изначально дизайном фреймворка и продвинутыми техниками С++ (метапрограммирование). Дай мне железку, и я под неё сконфигурирую data layer, оптимально её утрилизирующий.

Тогда как если ты возьмешь тот же PG, то у тебя на руках черный ящик с древней архитектурой для позапрошлого поколения железа, который хрен научишь тому, что тебе надо. Вот если бы PG «открылся бы», стал бы фреймворком, из компонентов которого можно было бы собирать свои СУБД под свои нагрузки, то это была бы другая история. Они там, хотя бы, storage смогли от процессинга абстрагировать уже?