← All posts tagged любопытство_и_деменция

BradleyManning
любопытство_и_деменция Конечно, лучше на SO спрашивать, но там ведь скажут что оно opinion based или как его там и заморозят.
Короче, нужно хранилище, которое скейлится и без головняка — чтобы не разваливалось, с транзакциями и без стремных ограничений.
Смысл в том, чтобы иметь exit strategy — всегда можно сказать, что в случае сильного роста нагрузки мы перейдем вот на то хранилище, но только чтобы по честному — на него реально можно перейти.
Куча вариантов отпадает потому что на весь кластер одна нода пишет. У foundationdb слишком сильные ограничения на транзакцию (и масштабирование под вопросом) — пока-что оно ближе всего к идеалу. NDB cluster выглядит отлично, но он развалится. TiDB выглядит отлично, развалится или нет — вопрос, скейлится хорошо, но очень медленный. Что там еще есть?
BradleyManning
любопытство_и_деменция Ученые обсуждают, на сколько лет жизни рассчитан человеческий организм. 120? Больше?

Вот ведь в говне мочёные, ваще не соображают. Человеческий организм рассчитан на 40 лет. Потом он рассыпается, но этот процесс может занять в особо запущенных случаях до 80 лет.
BradleyManning
любопытство_и_деменция Илья напомнил про черную дыру для данных под названием Кафка
aphyr.com
Заглянул к Кайлу, посмотрел чё нового. Ура! Редпанду тоже погоняли.
jepsen.io
Тоже черная дыра для данных.

Сцуко, вроде не самая сложная задача, неуж-то нету нормального сервиса для таких штук? Кассандру не предлагать, тоже просирает aphyr.com
BradleyManning
любопытство_и_деменция Так, че-то я туплю.
Берем ред панду (это такой клон кафки, не думаю что с кафкой что-то поменяется), пишем три строчки на ноде, которые на каждый пришедший запрос кладут в топик какой-то мусор.
Натравливаем wrk — всё офигенски, все летает, пока из любопытства не говорим wrk — а теперь попробуй то же самое, но только на двух соединениях. И тут панда начинает сыпать Local: queue is full. Вроде, от объема мусора не зависит — можно по 20 байт класть, можно по 200к, можно все что между. Количество соединений, кажется, тоже не важно если их не слишком мало. Вот когда два — начинается.

Два соединения — это изврат, который на практике не встретится. Но мне важно понимание, почему так происходит? Нужна ментальная модель. А нету.
BradleyManning
любопытство_и_деменция Поиски embedded db для .net

LiteDB: Периодически всплывают баги, приводящие к нарушению структуры базы и делающие её нечитаемой. habr.com

RavenDB: octopus.com ну да, старое, но тоже жалуются. Вроде, они так и оставили такую систему индексирования, так что вылечиться не должно.

FASTER: с ихним API буквально всё превращается в закат солнца вручную.

Остаются RocksDB, который небыстрый и геморойный, SQLite который все любят, но который медленней всех кроме совсем уж днища, и LMDB который single writer и на абсолютно типичной ситуации "много еденичных инсертов" будет плох.

Остальное в большей или меньшей степени Windows-only. Печаль.
BradleyManning
любопытство_и_деменция Есть такая штука — LMDB. А для неё есть обертка — lmdb-js. Ну, я уже пищал от радости про неё. А у неё есть такая штука, как commitDelay в опциях, что для single writer базы весьма пользительно. А для всех трех дотнетовских оберток для LMDB ничо такого нету, вроде. Самому колхозить такое религия запрещает — я криворукий еблан, любой код с конкурентностью в моем исполнении рано или поздно отправит данные в /dev/null. Чо, блин, делать...

Не спрашивайте — зачем, я просто развлекаюсь.
BradleyManning
любопытство_и_деменция Может, я страдаю фигней и не в курсе просто. Как нодовские процессы (которые cluster.fork) прибить гвоздями к конкретному ядру? И по слову pinning, и по слову affinity на npmjs какая-то ерунда.

Может, я дурью маюсь и оно само уже так делает?
Или придется как последнему лоху самому taskset дергать?
BradleyManning
любопытство_и_деменция Вот есть никому не интересный CedrusDB. Ковыряют что-то там потихоньку, обещают да не выкладывают сорцы. Но! Они не поленились пробенчмарить faster, lmdb и rocksdb.
Это первый независимый бенчмарк для faster который мне попался, да еще с правильными базами, а не с хрен знает чем.
arxiv.org