Ну что, поехали дизайнить новый сторейдж с учётом всех недостатков текущего. Что мы знаем / чего нам не хватает / что хочется
Пересобрал с отладочной информацией, прочитал про средства отладки на маке (много, но все какие-то не такие), ждёшь зацливания — а оно не зацикливается уже 12 часов. Btw, я научился понимать, что на маке зациклилось — он становится тёплым. Просто щупаешь, и если теплое — переключаешь KVM на мак. Напоминает, когда я учился водить на старом опеле — определял воткнутую передачу по запаху. Пахнет палёным — значит, третья. Не пахнет — значит, первая.
Собственно, для rocksdb есть на самом деле относительно вменяемые биндинги сейчас, без той дичи, что была когда-то со сборкой. Но есть гипотеза, что имея небольшой набор относительно простых примитивов — можно собрать себе СУБД под свои нужды. git же не стал прикручивать sqlite или rocksdb - хотя по сути то, что у гите и есть иммутабельная субд - pack файлы + индекс в виде хэштаблицы. Интересно, что примитивы-то получаются очень простые, а работать с сырой замапленной памятью совсем просто и вроде как, это всё работает не хуже, чем "настоящие системы". Ну посмотрим, конечно. Удивительно, что вещи, которые сначала кажутся сложными — на деле оказываются совсем не сложными (дисковые хэштаблицы, например. столько времени не мог к ним подойти)
Интересное: даже самый всратый метод записи работает не сильно-то хуже, чем моднейший. иногда всратый получается быстрее: например у меня на AMD-боксе слабый nvme, но больше ядер - и тупое написать в n потоков пачки мелких файлов — работает побыстрее, чем "правильный" способ записи (append-only лог в один поток).
Кстати согласно тестам (fio, dd), писание в несколько потоков ничего практически не даёт - ну т.е прирост есть, но не настолько большой, что бы ради него усложнять.
Ну т.е оно пишется примерно с максимальной скоростью, на которую способен диск что так, что сяк. Сложно ухудшить.
Но всё таки на нормальном диске разница таки есть, но маленькая:
А вот с чтением ситуация уже другая
Кстати согласно тестам (fio, dd), писание в несколько потоков ничего практически не даёт - ну т.е прирост есть, но не настолько большой, что бы ради него усложнять.
Ну т.е оно пишется примерно с максимальной скоростью, на которую способен диск что так, что сяк. Сложно ухудшить.
Но всё таки на нормальном диске разница таки есть, но маленькая:
[dmz@expert:~/w/hbs2]$ time hbs2 store ~/Videos/GX010021.MP4
AmAFa69anzN9hsUvprsjxAZFrngaVhrPUXUbxFV78hqC
real 0m2,223s
user 0m3,455s
sys 0m0,957s
[dmz@expert:~/w/hbs2]$ time ./test-cq-storage test:ncq:raw:merkle:write ~/tmp/ncq1/ ~/Videos/GX010021.MP4
[debug] currentFileName /home/dmz/tmp/ncq1/0/current.data
stored in 3.334689417 0.959003
AmAFa69anzN9hsUvprsjxAZFrngaVhrPUXUbxFV78hqC
[debug] WIP: ncqFixCurrent
[debug] ncqFixIndexes
[debug] WIP: ncqStorageLoadIndexes
[debug] RUNNING STORAGE!
real 0m2,077s
user 0m2,811s
sys 0m1,464s
А вот с чтением ситуация уже другая
Про сторейджи (микробенчмарки по ссылке)
https://hbs2.net/tree/Fih9vUk6BjJFRuenCAsZUS5M8kD2UZHRPfNGKZGbQghf
видно, что sqlite (btree) не так уж плох на небольшом объеме подобных данных (хэши), но с какого-то момента начинается уже заметная деградация. А ведь это он в самом благоприятном режиме — все записи пакетом одной транзакцией и отсутствие конкурентных чтений в процессе.
На чтение ~ в 20 раз хуже. На запись сначала не хуже, но начиная с миллиона записей уже хуже. Первый тест — текущая схема "git like storage" - т.е на каждый блок запрашиваем один файл. Там, конечно, еще проезд через unix socket по RPC, но он очень мало занимает. Итого в 10 раз хуже sqlite, который в 20 раз хуже ncq (новый самодельный сторейдж).
Ну, ок. Новый сторейдж уже почти тут. Осталось сделать компакции (наверное), удаление (за один проезд с компакцией) + миграцию (собственно, она уже тут:
https://hbs2.net/tree/Fih9vUk6BjJFRuenCAsZUS5M8kD2UZHRPfNGKZGbQghf
видно, что sqlite (btree) не так уж плох на небольшом объеме подобных данных (хэши), но с какого-то момента начинается уже заметная деградация. А ведь это он в самом благоприятном режиме — все записи пакетом одной транзакцией и отсутствие конкурентных чтений в процессе.
На чтение ~ в 20 раз хуже. На запись сначала не хуже, но начиная с миллиона записей уже хуже. Первый тест — текущая схема "git like storage" - т.е на каждый блок запрашиваем один файл. Там, конечно, еще проезд через unix socket по RPC, но он очень мало занимает. Итого в 10 раз хуже sqlite, который в 20 раз хуже ncq (новый самодельный сторейдж).
Ну, ок. Новый сторейдж уже почти тут. Осталось сделать компакции (наверное), удаление (за один проезд с компакцией) + миграцию (собственно, она уже тут:
time cat all | ./test-cq-storage test:ncq:raw:write-some ~/tmp/ncq1 ), на 50G займет минут десять, если не делать фоновую (обсуждаемо).При всех своих достоинствах — stm опасная фигня. Своим наличием провоцирует её использовать, что, в свою очередь, чревато продолжительными неприятными приключениями. Особенно, когда привыкаешь, что всё просто работает, а потом сочетание retry и очередей. Было б круче, конечно, если бы был вариант рантайма наподобие эрлангового. С отдельным хипом и gc на процесс, а еще лучше - с возможностями выбрать разные аллокаторы (или хотя бы разные параметры gc) на процесс
я просто к тому, что в эрланге нихрена нет, а всё работает. может, в этом и есть сермяжная правда
В разработке долгоживущих серверов и embedded программ очень много общего.
Настолько много, что это, кажется, одна и та же задача, только для серверов добавляется аспект большого количества данных / RAM / disk.
В embedded невреден аппаратный вочдог, который работает независимо от mcu, какая-нибудь байда, которая по истечению таймаута ресетит mcu если ей это явно не отменили. типа детонатор "мёртвая рука".
В хаскельном сервере вот вскрылся интересный нюанс — если у нас приключилось что-то внутри stm, то залипнет так, что никакой написанный на хаскелле же внутренний вочдог не поможет — клинит намертво всё, при том, что далеко не все ядра, например загружены. Максимум одно. Это так-то довольно логично, но что с этим делать не очень понятно. Нужно разработать какую-то дисциплину, которой придерживаться, но она влияет на вообще все аспекты.
Кажется, что эрланговый подход, хоть и предположительно тормознее, но более положительно сказывается на живучести в силу нормальной изоляции процессов.
На хаскелле можно его эмулировать, но это надо прямо всю волю в кулак собрать, и писать не как пишется, а как надо (а хрен его знает, как надо).
Насчёт вочдога поможет, конечно, например, сишный/еще какой лаунчер — который будет форкать хаскельный процесс и управлять его рестартом, а так же работать вочдогом. Конечно, хочется не сишную, а на том же хаскелле - пока что придумываю какой-нибудь кунштюк, что бы это сделать.
Некоторые называют такую пускалку "systemd", но я хочу
1) пускать в консолях / tmux-ах и смотреть разноцветные логи, а не journalctl этот ваш
2) не исключаю миграцию (свою) на платформы, где нет systemd
3) так или иначе большой проблемы сделать такую запускалку не вижу, хотя на си будет неизящно.
буду думать, короче
Настолько много, что это, кажется, одна и та же задача, только для серверов добавляется аспект большого количества данных / RAM / disk.
В embedded невреден аппаратный вочдог, который работает независимо от mcu, какая-нибудь байда, которая по истечению таймаута ресетит mcu если ей это явно не отменили. типа детонатор "мёртвая рука".
В хаскельном сервере вот вскрылся интересный нюанс — если у нас приключилось что-то внутри stm, то залипнет так, что никакой написанный на хаскелле же внутренний вочдог не поможет — клинит намертво всё, при том, что далеко не все ядра, например загружены. Максимум одно. Это так-то довольно логично, но что с этим делать не очень понятно. Нужно разработать какую-то дисциплину, которой придерживаться, но она влияет на вообще все аспекты.
Кажется, что эрланговый подход, хоть и предположительно тормознее, но более положительно сказывается на живучести в силу нормальной изоляции процессов.
На хаскелле можно его эмулировать, но это надо прямо всю волю в кулак собрать, и писать не как пишется, а как надо (а хрен его знает, как надо).
Насчёт вочдога поможет, конечно, например, сишный/еще какой лаунчер — который будет форкать хаскельный процесс и управлять его рестартом, а так же работать вочдогом. Конечно, хочется не сишную, а на том же хаскелле - пока что придумываю какой-нибудь кунштюк, что бы это сделать.
Некоторые называют такую пускалку "systemd", но я хочу
1) пускать в консолях / tmux-ах и смотреть разноцветные логи, а не journalctl этот ваш
2) не исключаю миграцию (свою) на платформы, где нет systemd
3) так или иначе большой проблемы сделать такую запускалку не вижу, хотя на си будет неизящно.
буду думать, короче
В начале этого всего я не хотел делать по возможности TCP, думал (где-то с 2018 - 2019), что можно обойтись без него. Потому, что считал, что TCP это большой геморрой, связанный с управлением ЖЦ соединений, особенно в P2P системе. Теперь, по прошествии лет, могу сказать, что на самом деле TCP это большой геморрой, связанный с управлением ЖЦ соединений, особенно в P2P системе.
И конечно, могу сказать, что цикл REPL в трое суток это лучше, чем REPL вида (поставил GPS трекер на автобус - отпустил автобус - автобус пропал с радаров из-за бага - ездишь на машине по тамбовской области и ищешь автобус, что бы посмотреть, что с трекером) — но всё равно напрягает.
В соседних чатах продолжают жаловаться на ущемления со стороны гитхаба, и атаку клоунов ботов на опенсорсные репозитории, где (видимо написанные на js) краулеры AI кладут опенсорсную инфраструктуру, вроде sr.ht
Не то, что бы P2P подход решал этот вопрос полностью, но он точно решил бы его как в моменте, так и в перспективе — т.е если отключить HTTP для получения деревьев, то ботописатели будут вынуждены пользоваться фреймворком, который балансирует нагрузку по пирам.
Кроме того, везде, где возможно спроектировано так, что бы основную нагрузку нёс запрашивающий.
Занятно, что текущая ситуация с AI ботами отличается от поисковиков двумя вещами:
1) поисковики удушили свой собственный поиск по исходникам (т.к. он не в их интересах)
2) криворукость нынешних ботов, которые просто кладут на соблюдение всяких приличий (robots.txt)
Не то, что бы P2P подход решал этот вопрос полностью, но он точно решил бы его как в моменте, так и в перспективе — т.е если отключить HTTP для получения деревьев, то ботописатели будут вынуждены пользоваться фреймворком, который балансирует нагрузку по пирам.
Кроме того, везде, где возможно спроектировано так, что бы основную нагрузку нёс запрашивающий.
Занятно, что текущая ситуация с AI ботами отличается от поисковиков двумя вещами:
1) поисковики удушили свой собственный поиск по исходникам (т.к. он не в их интересах)
2) криворукость нынешних ботов, которые просто кладут на соблюдение всяких приличий (robots.txt)
Удаление из нового сторейджа сделал, работает быстро, потому что удаление это добавление. удивительно, сколько вылазит сразу неочевидного, например "добавили удалили добавили удалили добавили..." - короче это CRDT со счётчиком удалений + несколько оптимизаций в моменте (которые мешают жить потом). Теперь вот думаю, как сделать компакцию этого всего, да так, что бы онлайн работало, да автоматом запускалось, да кукухой не поехать, да файловые дескрипторы бы не вытекли и в корку бы не падало ( mmap-нутые файлы в хаскелле умеют/могут)
А нельзя ли принять какой-то закон, что все российские сайты обязаны быть в домене .ru ? а если не в домене .ru то не имеют права запрещать доступ с иностранных ip. Ну либо закон, обязывающий firefox запускать разные инстансы с разными настройками прокси, но firefox пошлёт, конечно же.
Вообще можно сказать, что компакция в реальном времени/инкрементальная не сделана в разных БД не потому, что они придурки и не осилили, а потому, что это очень непросто и порождает проблемы, которые не хочется решать иммутабельных системах, напротив, от этого всего хотелось как раз уйти. Даже из того, что сходу видно там (с реальным временем) порождаются дичайшие гонки, и решения в стиле "делаем так, а если к концу действия произошло вот это — то откатываем операцию целиком". Чот too much для наколеночной БД. Короче, я пока придумал только половину инкрементальной компакции в реальном времени, а вторую чот никак не могу.
На чём бы можно было помоделировать сторейж, например? TLA+? допустим? т.е допустим сделать некую модель, проверифицировать алгоритмы, а потом из неё сгенерить код. Не сэкономило бы это время, по сравнению со "сделал - частично работает - сидишь отлаживаешь". Т.е есть ли реальные кейсы, как применение подобных инструментов сэкономило время?
Заставляем LLM обучать нас TLA+ -> вместе пишем модель -> генерим код в рамках имеющихся примитивов -> заставляем модель проверять соответствие модели коду -> профит. Кто-то уже пытался?
Говорящая собака подогнала почитать: https://lamport.azurewebsites.net/tla/book.html
Что бы дать отдохнуть мозгам, решил сделать бота для печати анкет для аэроклубов. ознакомился с 152-ФЗ и у меня много вопросов. Ну так-то конечно быстрый вывод после ознакомления — данунегонахуй, особенно бесплатно. Второй вопрос — а что, вот те крупные всем нам известные операторы персональных данных от которых данные утекают прямо в день появления — и потом нам звонят из службы безопасности сбербанка — они какую-то ответстенность за это несут/понесли? Или им можно? Ну и третий вопрос — а не цирк ли безопасности ли это всё и не инструмент ли вытеснения мелких игроков с рынка.