Комментарии 18
Прошу прощения, что вмешиваюсь, но если вы пишете систему поиска по векторам, то рекомендую присмотреться к Vearch.
https://github.com/vearch/
Это система, написанная в jd.com, она уже отлажена в проде на сотнях миллиардов векторов и работает достаточно стабильно.
В свое время у меня была задача сделать подключение в Go хранения данных в KV хранилищах. Долго не мог выбрать, и в итоге сделал "универсальную" обертку с несколькими бэк-эндами. https://github.com/reddec/storages
Бонусом: всякая разная типо-безопасная кодогенерация. Возможно будет интересно.
Простите, но ваша бд — это
type Records struct {
mtx sync.RWMutex
store *storage
}
Это не про параллелизм и оптимизацию на конкурентный код.
Я как-то видел симпатичную инфографику в какой-то статье здесь на Хабре, в ней, если мне не изменяет память, в круговой диаграмме было разрисовано, сколько и чего делают современные БД, и работа с данными там занимала весьма небольшую часть круга. Но замечание ваше принимаю, и если и когда я сделаю такие изменения, я с удовольствием поделюсь этой новостью с вами и сообществом, возможно, результат будет гораздо оптимистичней, чем я ожидаю (вот и ещё один пункт в ToDo).
При каких условиях не является? При скольких потоках выполнения и логических ядер?
Проблем несколько, одна из них в том, что лок один. И это быстро убивает прирост от увеличения ядер/процессоров(в гошном смысле).
Но как и всегда, всё надо проверять хорошими и воспроизводимыми бенчмарками.
Lockfree тоже не бесплатно и не панацея.
На мой взгляд, нет двух ключевых вещей: для кого эта база и обертка, каков у пользователя сценарий; зачем-то захардкожены зависимости, начиная с логгера.
*Базы и нужды бывают разные. Или вы про то, что если все базы усреднить? Тогда это вряд ли полезно будет.
Про параллелизм: я думаю, что понимаю вашу мысль, т.к. мне приходилось делать библиотечку, рассчитанную выжать как можно больше из ядер, и чем их больше (ядер), тем лучше. Эта мысль логичная и не противоречит мои планам.
Ящик для хранения данных в go-приложениях