Посоветуйте embedded db с c/c++ интерфейсом и опытом использования в проде

Посоветуйте embedded db с c/c++ интерфейсом и опытом использования в проде. Задача индексация видео архива (~объем одного архива 30 тб), необходим механизм ttl ("протухание") индекса, не точный поиск индекса (нахождение ближайшего слева или справа), добавление индексов на лету, удаление только старых, добавление возможно в "середину", желательна возможность создания снэпшотов. Основная проблема текущего решения (все индексы загружены в rb tree, индексы в стрктуированых файлах ) откушивает память и протухание, вставка в середину - перебалансировка.

557   10  
Создание веб сайтов

Comments

  1. Konstantin Kivi
    Reply
    Konstantin Kivi 5 лет назад
    30тб - это грубо 30 тысяч видео?
  2. Yu Ersh
    Reply
    Yu Ersh 5 лет назад
    sqlite
  3. Alex Tutubalin
    Reply
    Alex Tutubalin 5 лет назад
    А что в индексе то? Только время записи или еще что-то?
  4. Макс Лапшин
    Reply
    Макс Лапшин 5 лет назад
    Оу, знакомая задача. Мы то у себя в флюссонике такое делаем давно и у нас многослойный индекс (несколько слоев на диске, ещё в памяти) с динамической подгрузкой (т.е. умеем не давать сквида на старте).<br><br>Как верно подсказали выше, данные уже _почти_ сортированы по времени, за исключением кластерного копирования.<br><br>30 ТБ — это очень маленький архив, вам не нужны какие-то мегаскорости на нём. Это же один небольшой сервер под видео.<br><br>У вас точно не петабайты?
  5. Ilya Golshtein
    Reply
    Ilya Golshtein 5 лет назад
    С нахождением ближайшего слева или справа sqlite, наверное, справится. Зависит от того, как у него реализован LIMIT и ORDER BY.<br>Зачем вам lsm tree, у вас реально интенсивная запись? Причем тут это?<br>Почему вставка в середину вызывает перебалансировку (и что такое в вашем случае перебалансировка)?
  6. Vitaly Levchenko
    Reply
    Vitaly Levchenko 5 лет назад
    На этом масштабе же весь индекс в память влезает — зачем вам выстраиваемая БД?
  7. Антон Герасимов
    Reply
    Антон Герасимов 5 лет назад
    Под вашу задачу хорошо подойдёт time series db и поверх серий сделать слой чанков на какой-нибудь rocksdb (если готовы в ней ковыряться).<br><br>Восстановление и синхронизацию делать на уровне чанков т.е более крупных частей, а не отдельных записей индекса.<br><br>Готового для этой задачи ничего не помню, но реализуется она вполне понятным способом, а дальше -- бесконечный тюнинг и оптимизация пограничных случаев.
  8. Андрей Якубовский
    Reply
    Андрей Якубовский 5 лет назад
    Макс Лапшин Alex Tutubalin спасибо, ответы подтолкнули к допиливанию своего велосипеда, шагов то осталось сделать не много :), если вдруг у кого-то будут мысли по теме, поделитесь плз. :) спасибо
  9. Александр Астреинов
    Reply
    Александр Астреинов 5 лет назад
    .Под вашу задачу подойдет программист с большим опытом
  10. Андрей Якубовский
    Reply
    Андрей Якубовский 5 лет назад
    создание мета-индекса решило проблему неэффективного использования памяти. мета-индекс строится над чанками индексных файлов (чанки - часовые индексы видео-архива), запись через aio. чтение pread. утилизация сpu и памяти снизилась 1000 стримов 15-20% сpu (48 ядер xenon gold) память ~15 GB (было ~40). экспресс тест RocksDB показал не состоятельность идеи запихивать упорядоченные таймсириес данные в бд. спасибо.
Click here to cancel reply.