Э
Size: a a a
2020 August 23
e🦀
Еще можно LSM-tree взять вместо B-tree, говорят, оно лучше на запись при такой же скорости чтения. Юзается в embedded DB sled: https://github.com/spacejam/sled
AV
A
Ну, скажем так, последниц коммит 2016 года, фиг его, нужно разбираться в код смотреть, ну и плюс они там левого понаписали, типо WAL, а мне это как бы в свою бд и не надо, а если и надо, то по другому))
A
Еще можно LSM-tree взять вместо B-tree, говорят, оно лучше на запись при такой же скорости чтения. Юзается в embedded DB sled: https://github.com/spacejam/sled
LSM да, но нет)) во-первых, моя задача не тупо переписать sled, а во-вторых, это немного для другого вида баз данных используется, ну т.е. чуточку для другой архитектуры, мне нужно что-то типо LMDB повторить, а там не совсем подойдет lsm… кароче это уже не в раст чатике обсуждать 😃
A
Еще можно LSM-tree взять вместо B-tree, говорят, оно лучше на запись при такой же скорости чтения. Юзается в embedded DB sled: https://github.com/spacejam/sled
Если что я вот отсюда тоже брал инфу по этому поводу https://tikv.org/deep-dive/key-value-engine/b-tree-vs-lsm/ А так как у моей бд будет больше чтения чем записи, то разумнее b+tree будет, потому что используя lsm еще прийдется кеширование писать поверх… Ну в общем я вас понял, спасибо за подсказку о том, что писать проще самому))
b
приветствую, кому не сложно не могли бы кто-нибудь взглянуть на код и подсказать, возможно как правильнее было бы написать
MB
приветствую, кому не сложно не могли бы кто-нибудь взглянуть на код и подсказать, возможно как правильнее было бы написать
Как-то многовато потоков создается.
b
это нормально, чтобы побыстрее было. канал позволяет
MB
100+ потоков явно ненормально.
b
на го когда реализовал подобное ставил 512-1024 потоков
MB
на го когда реализовал подобное ставил 512-1024 потоков
Потоков или горутин?
b
горутин
MB
Ну вот поток это никакая не горутина
b
понимаю, что здесь всё-таки поток, но судя по top довольно дешево и не грузит систему, почему бы и нет?
b
вот думал, что всё-таки вместо thread::spawn надо на async переделать, но разницы в скорости я не думаю, что прибавится, почему не использовать >100 потоков? гонок за данными нет, скорость работы приемлимая, и она самое главное в программе. Чем быстрее тем лучше
E
вот думал, что всё-таки вместо thread::spawn надо на async переделать, но разницы в скорости я не думаю, что прибавится, почему не использовать >100 потоков? гонок за данными нет, скорость работы приемлимая, и она самое главное в программе. Чем быстрее тем лучше
"почему не использовать >100 потоков?"
вы неограничены в ресурсах системы?
вы неограничены в ресурсах системы?