Парни, вопрос от фронтендера. Какой брокер очередей взять? Юзал только

редис, но как-то оно не очень надёжно, имхо

rabbitmq

А у нас что-то везде NATs пихают в проектах

И как оно?

Норм, пашет

kafka уже предлагали?)

так она ж только когда у вас тысячи и миллионы этих сообщений?

Ну там дальше человек вроде бы говорил про тысячи мелких сообщений, вот я и подумал))

А она хорошо работает именно с маленькими сообщениями? Человек писал, что они там в несколько байт

Сам не юзал, но когда читал инфу про написание своей базы данных изучал принцип устройства кафки и рабита, так вот поидее кафка то как раз больше подойдет для мелких сообщений, чем рабит, потому что у кафки принцип работы строится на Pull механике, а не на Push как у рабита. Ну типа там внутри по сути тупо массив, который наполняется данными сколько угодно тем кто генерит эти сообщения, а тот кто читает просто запоминает грубо говоря индекс последнего забранного значения и одним pull запросом может считать с любого места все оставшиеся данные. Т.е. проблема только в размере индекса, но думаю с этой же проблемой столкнется и рабит, но тут я не уверен, не разбирал устройство рабита, помню только что он к сообщению еще кучу данных лепит сверху, что поидее может наделать овердохера лишней инфы. В общем не буду утверждать 100% верности моей информации, если есть что сказать, буду рад узнать 😊

вот поэтому надо хотя бы раз написать свою БД)))

Бд таки написали?

Пишу на Rust ))) Но как бы пока что только продумал структуру самой бд в файле, и архитектуру в Rust продумал, написал простейшее добавление данных и их вытягивание, ни о каком удалнении переменных еще речи нет 😅

Потихоньку пишу в свободное время))

а реляционная бд или как?

embedded key value, вдохновлялся LMDB, но там слишком жесткое ограничение на 1 writable transaction и libmdbx пытались это исправить до 3 подняли, но в итоге тоже решили переписать все к хренам 😂

реалиционная

Так есть же популярная от фейсбука

RocksDB использует WAL)) А что в lmdb что у меня нет этого говна))

lmdb знаком, но оно вроде как очень старое. С wal незнаком

И что, что старое?)) ну есть новее libmdbx по сути переписанный lmdb )) Но как бы mysql и postgres тоже то еще гавно мамонта вместе с ораклом )))))

mysql вроде большее говно, там даже сравнение по размеру кодовой базы было

я так и не смог libmdbx скомпилить )))

киньте потом ссылку на гитхаб, оценим говнокод ваш)

О говнокод Я за грамотность

fixed

Ну как бы надо еще дописать хотя бы до mvp 😅 уже потом что-то показывать)))

а key-value с запросом на получение значение по ключу за О(1)?

Ну как бы вам никто не даст O(1) скорость чтения, если у вас нет индексов 🤣 у меня в самом плохом случае O(n), но типа я заложил индексирование данных, в отличие от lmdb в котором в лучшем случае O(log n) из-за b+ tree. Так вот я собирался добавить парочку разных индексов, такие как хеш, который O(1) выдает, но имеет коллизии, как b+ tree ( O(log n) ), как ART tree (Adaptive radix tree) не помню сколько, как R tree и возможность добавления любых индексов, которые в дальнейшем могут понадобиться, потмоу что данные же могут лежать разные 😉

я далеко не спец в (key-value) бд, но например тот же редис пише что GET <key> выполнется за O(1) поэтому и спрашиваю, типа есть ли смысл писать key-value бд в которой чтение и запись не за O(1) ?

Да это невозможно

а в б дереве поиск o log n? я чет забыл

ну редис то in-memory

тогда отбой

а я чет не понял, что вы за админ такой?) еще не видел в чате раньше

key-value разные бывают, какие-то чисто для чтения, какие-то для записи O(1) дают, но у каждого из этих способов есть свои минусы, нельзя сделать и чтение и запись за O(1). В redis не разбирался что внутри, но O(1) это хеш индексы, типа как md5 (очень грубо говоря), но более навороченные, и нужно смотреть, что они там с коллизиями делают, там или вариант перезаписать старые данные при добавлении или хранить все значения, но и тот и тот вариант имеют свои минусы)) В общем не получится у вас читать и записывать за O(1) темболее в диск))

ох зря вы md5 в хэш индексы приперли))

Хэш тейбл как раз O(1) на чтение и запись

Ну да) b tree Algorithm Average Worst case Space O(n) O(n) Search O(log n) O(log n) Insert O(log n) O(log n) Delete O(log n) O(log n)

Смотря какая хеш тейбл)))

ну да, может же быть O(1.3), медленее будет :D

если не O(1) то это уже не хештейбл

обычно ж худший вариант рассматривается?)

нет

average case?

да.

Опять же… Algorithm Average Worst case Space O(n) O(n) Search O(1) O(n) Insert O(1) O(n) Delete O(1) O(n)

пасиба за напоминание))

😊

O(1) amortized, или O(1+n/k), O(1) это в среднем

Вы опоздали)) надо было приходить раньше))

А, да, сорь тогда )