БД это достаточно сложная штука чтобы довериться бенчмаркам, так как у бд очень много неизвестных переменных(ram, cpu, disk, os+конфиг, окружение) В любом хотябы минимально серьёзном сервисе всегда конфигурируют хранилище под свои нужды(пул коннектов, размеры чанков с данными, периодичность автоперестройки индексов, доступная память, доступные ядра проца...) Например для более сложных бд для работы с данными разных размеров можно смонтировать отдельный диск с оптимальной фс по размеру блока и конкурентному доступу к данным для ускорения IO операций и уже для этих параметров конфигурировать размеры чанков в базе(в некоторых случаях это уже может дать ощутимый прирост скорости или иметь обратный эффект) Процессор может дать прирост по скорости если для бд актуально использование многопоточности, если в бд есть какойнибудь кэширующий слой, то тут может играть роль и архитектура(в случае арма данные не будут запрашиваться за пределами чипа и будет значительно быстрее) OC все разные и нельзя забывать про работу планировщика, как программа захватывает и освобождает память. Особо интересные моменты возникают при загрузке памяти ближе к 80%, тогда данные начинают лететь в своп и неизвестно какие данные и когда там окажутся, что можно снизить скорость работы базы + не всегда есть своп или стратегия своппинга может быть не дефолтной и тогда memory manager начинает всё подряд уничтожать. Про бенчмарки, они ненадёжные в плане результатов. На них влияют другие приложения в системе и могут дать неточный результат с достаточно большим отклонением, которые делают результаты ненадёжными, для этого режут нагрузку на проц, чтобы один бенчмарк не использовал 100%, а другой 26% В случае проверки на аллокации бенчмарки подойдут, а если нужно в продакшн гденибудь в ECS деплоить, то только без нагрузочного тестирования можно словить кучу сюрпризов которые не покажут бенчмарки
Абсолютно точно, да 🙂Спасибо за такое подробное дополнение! Бенчмарк лично для меня тут больше как первый шаг, чтобы пощупать механизм хранения. Для остального я обычно сразу пишу прослойку, чтобы в реальном проде на шаге тестирования сделать какие-то выводы, и либо тюнить конкретную базу, либо взять другую сразу. Но всё действительно очень вариативно в зависимости от данных и ресурсов
Спасибо! Смотрел! LMDB - основной вдохновитель BoltDB, и во многом они похожи. Но тут больше дело в том, что я не нашёл реализации чистой LMDB на Go. А RocksDB под капотом использует LevelDB (только не гошную, конечно), но тоже написан не на Go. А прям в живых проектах, к сожалению, не юзал ни то, ни другое
Хорошее сравнение. Но можно сделать реальный пример использования таких БД? Можно записать видео, как сделать систему балансов пользователей как у банков? 1. Какую БД использовать для хранения истории 2. Какую БД использовать для обновления балансов, если использовать многопоточность и нужно обновлять балансы тысячи пользователей в секунду. 3. Как сделать защиту от внезапного выключения сервера, чтобы балансы пользователей были сохранены Также можно сделать бенчмарки, на ютубе таких примеров ровно ноль, сам столкнулся с такой задачей
О, тут прям ТЗ получилось)) Идея интересная, сам думаю в сторону демонстрации какого-то большого проекта на канале, но тут прям одним видео как будто не обойтись 🙂 Спасибо за мысли, что-то подобное обязательно запишу
О, круто! Ты о вот этой штуке github.com/asdine/storm ? А то там ещё есть вот такая github.com/CleverTap/stormdb , но она на Java, и вроде пока не увидел связи между ними
БД это достаточно сложная штука чтобы довериться бенчмаркам, так как у бд очень много неизвестных переменных(ram, cpu, disk, os+конфиг, окружение)
В любом хотябы минимально серьёзном сервисе всегда конфигурируют хранилище под свои нужды(пул коннектов, размеры чанков с данными, периодичность автоперестройки индексов, доступная память, доступные ядра проца...)
Например для более сложных бд для работы с данными разных размеров можно смонтировать отдельный диск с оптимальной фс по размеру блока и конкурентному доступу к данным для ускорения IO операций и уже для этих параметров конфигурировать размеры чанков в базе(в некоторых случаях это уже может дать ощутимый прирост скорости или иметь обратный эффект)
Процессор может дать прирост по скорости если для бд актуально использование многопоточности, если в бд есть какойнибудь кэширующий слой, то тут может играть роль и архитектура(в случае арма данные не будут запрашиваться за пределами чипа и будет значительно быстрее)
OC все разные и нельзя забывать про работу планировщика, как программа захватывает и освобождает память. Особо интересные моменты возникают при загрузке памяти ближе к 80%, тогда данные начинают лететь в своп и неизвестно какие данные и когда там окажутся, что можно снизить скорость работы базы + не всегда есть своп или стратегия своппинга может быть не дефолтной и тогда memory manager начинает всё подряд уничтожать.
Про бенчмарки, они ненадёжные в плане результатов. На них влияют другие приложения в системе и могут дать неточный результат с достаточно большим отклонением, которые делают результаты ненадёжными, для этого режут нагрузку на проц, чтобы один бенчмарк не использовал 100%, а другой 26%
В случае проверки на аллокации бенчмарки подойдут, а если нужно в продакшн гденибудь в ECS деплоить, то только без нагрузочного тестирования можно словить кучу сюрпризов которые не покажут бенчмарки
Абсолютно точно, да 🙂Спасибо за такое подробное дополнение!
Бенчмарк лично для меня тут больше как первый шаг, чтобы пощупать механизм хранения. Для остального я обычно сразу пишу прослойку, чтобы в реальном проде на шаге тестирования сделать какие-то выводы, и либо тюнить конкретную базу, либо взять другую сразу. Но всё действительно очень вариативно в зависимости от данных и ресурсов
Братан, хорош, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
Этот почерк ни с чем не перепутаешь 😂
Спасиибо!
Спасибо за ваш труд! Очень полезное видео! Успехов!
Спасииибо!
Спасибо за видео. Коммент в поддержку!
Спасибо большое!
Видео балдеж
Попытка номер 3
Вах, от души! Рад, что получилось
Красавчик ! Спасибо было очень полезно! ❤
Спасибо!!
Спасибо за годный контент, реп+
Спасиибо!
Вячеслав, спасибо Вам за это видео, очень помогло.
Очень рад, спасибо большое за комментарий!
Спасибо за видео! На движки lmdb, rocksdb не смотрели?
Спасибо! Смотрел! LMDB - основной вдохновитель BoltDB, и во многом они похожи. Но тут больше дело в том, что я не нашёл реализации чистой LMDB на Go.
А RocksDB под капотом использует LevelDB (только не гошную, конечно), но тоже написан не на Go. А прям в живых проектах, к сожалению, не юзал ни то, ни другое
Спасибо за видео! Что за текстовый редактор, показанный в видео?
Спасибо за коммент! А это GoLand от Jet Brains в новом дизайне
Хорошее сравнение. Но можно сделать реальный пример использования таких БД?
Можно записать видео, как сделать систему балансов пользователей как у банков?
1. Какую БД использовать для хранения истории
2. Какую БД использовать для обновления балансов, если использовать многопоточность и нужно обновлять балансы тысячи пользователей в секунду.
3. Как сделать защиту от внезапного выключения сервера, чтобы балансы пользователей были сохранены
Также можно сделать бенчмарки, на ютубе таких примеров ровно ноль, сам столкнулся с такой задачей
О, тут прям ТЗ получилось))
Идея интересная, сам думаю в сторону демонстрации какого-то большого проекта на канале, но тут прям одним видео как будто не обойтись 🙂
Спасибо за мысли, что-то подобное обязательно запишу
а можно будет как нибудь видео о работе с гугл шитс?
А что именно интересует? Работа по API?
Интересно, а какая будет разница с Redis (например, на той же машине по сокету, но не обязательно), чисто чтобы понять порядок цифр?😁
Вызов принят, на неделе отпишусь))
Обещал, отписываюсь! Воть ruclips.net/user/shortsGsT0XrSbk7w (ну и конечно в табличке тоже добавил инфу)
@@VyacheArt огонь! спасибо за скорость :)
p.s. да, цифры не однозначные, занятно)
А к болту ещё есть StormDB ) от asdine )
О, круто! Ты о вот этой штуке github.com/asdine/storm ? А то там ещё есть вот такая github.com/CleverTap/stormdb , но она на Java, и вроде пока не увидел связи между ними
@@VyacheArt да, я о первой
У болта так-то тоже транзакции есть)
Да, из трёх либ полноценных транзакций нет только у LevelDB