Добрый день.

Посоветуйте пожалуйста решение NoSQL исходя из моих требований:

1) хранилище должно размещаться в локальной сети (не в интернет-облаке типа Amazon)
2) сервер должен быть на винде (линукс не подходит)
3) будут храниться файлы размером ~100КБ-16МБ каждый
4) файлов может быть много (до 1 млн. новых в день)
5) нужна простая выборка key-value и возможность удаления старых файлов
6) интерфейс клиентского API - C/C++
7) чем проще и надежнее решение - тем лучше

Вроде как CouchBase подходит? или Oracle NoSQL?

Спасибо.

даже не хочется комментировать ваш вопрос...
проведите тесты сами и посмотрите производительность при млн. файлов и файловой системе
к тому же при удаленном расположении машины сервера сетевая шара - не вариант, нужно решение по-надежней

Зачем тогда по вашему разрабатывают NoSQL-сервера? От нечего делать?
Я не собираюсь вам здесь ничего доказывать. Не можете посоветовать - просьба не писать.
Спасибо.

nolockyvictorovichДобрый день.

Посоветуйте пожалуйста решение NoSQL исходя из моих требований:

1) хранилище должно размещаться в локальной сети (не в интернет-облаке типа Amazon)
2) сервер должен быть на винде (линукс не подходит)
3) будут храниться файлы размером ~100КБ-16МБ каждый
4) файлов может быть много (до 1 млн. новых в день)
5) нужна простая выборка key-value и возможность удаления старых файлов
6) интерфейс клиентского API - C/C++
7) чем проще и надежнее решение - тем лучше

Вроде как CouchBase подходит? или Oracle NoSQL?

Спасибо.

походу у автора дыра в голове и полное непонимание отличия файла от базы данных

в базе данных условно один файл на всё, остальное решается вопросами партицирования. партицирование по дню (отдельный файл бд для каждого дня) - это оок.

а вот тысячи файлов в день - за такое надо увольнять из отрасли, и принимать обратнотолько со сдачей экзаменов на вопрос ограничения количества файловых дескрипторов в системе.

Как раз и нужно чтобы был один файл и не было превышения дескрипторов. Для этого и прошу посоветовать NoSQL БД чтобы не связываться с ФС, которые изначально не были разработаны под такие объемы и кол-ва.
Файлы будут постоянно удаляться, более млн. врядли будет, но и добавляться новые.
Для таких целей NoSQL и разработали.
Или я в форум по философии попал? :)

Мог бы и сам такое написать чтобы в один файл все валило, но не хочется если уже есть хорошие готовые решения.

Сейчас использую SQLite, и разбивку по часам. Каждый час - новый файл. По чтению меня скорость устраивает, а вот по записи беда, я так подозреваю что SQLite после каждой записи делать Flush, потому производительность очень низкая. Плюс сетевого интерфейса у него нет, а нужен.

Да. Я прекрасно знаю что такое FS на низком уровне. Даже сам могу написать свою простейшую для такой задачи. Уж тем более знаком с NTFS, которая разрабатывалась лет 30 назад, когда и близко таких объемов и кол-ва не было. Куча мелких файлов на диске - это беда. Достаточно выполнить DIR C: /S и посмотреть на сколько повиснет, хотя это простой запрос типа SELECT name FROM Table
Относительно решений Oracle NoSQL / Berekley вопрос - можно ли их настроить так, чтобы кеширования почти не было и ОЗУ потребление сводилось бы к минимуму?

Dimitry SibiryakovvictorovichДостаточно выполнить DIR C: /S и посмотреть на сколько повиснет
Для уже вышеназванных почти 400к файлов на тормозном ноутбучном винте первый (холодный) запуск занял 4 минуты 19 секунд. Второй (с прогретым кэшем) - 52 секунды. Но какое отношение этот тест имеет к заявленному в стартовом посте "нужна простая выборка key-value"?..

Вы издеваетесь? Если у вас key выбирается только 4 минуты, а представьте если вы еще value (т.е. сами данные файла) начнете выбирать! Проведите такой эксперимент - очень простой: прочитайте все файлы с винта в "холодном кеше" c данными, заметьте время, а потом прочитайте по секторам весь логический диск С: подряд, чтобы кол-во секторов было сопоставимо с кол-вом данных всех ваших файлов (т.к. диск может не до конца быть забит). Увидите разницу. Вот второй способ - это примерно то, что будет в нормальном NoSQL-решении. Причины след. - дефрагментация самих файлов, что вызывает "бегание" головки жесткого диска (если он механический), а также структура FS не адаптированная для частых и больших выборок. Кеш конечно же есть, но не всегда он спасает, особенно если файлы обновляются.
Т.е. если я выбираю файлы в одной папке, то их поиск будет быстрее чем если они будут в азных папках на разных уровнях иерархии. А для key-value решения это не имеет значения.
В общем, если и дальше будете защищать NTFS как самое лучшее что есть на свете, то занимайтесь этим на другом сайте поклонников, но не в ветке форума NoSQL.

Даже не так - неправильный эксперимент.
Лучше такой - постройте заранее список всех файлов на вашем диске через тот же dir /S, а потом на холодном кеше попробуйте обращаться к файлам в случайном порядке из этого списка и пройтись по всем. Читать данные файла даже не нужно, просто читайте, к примеру, дату его создания. И такой процесс у вас зависнет минут на 20 - не меньше. Связано с тем, что dir выбирает файлы по иерархии, что чуть быстрее случайного обращения к файлам. А в нормальной DB обращение может быть случайным и должном быть быстрым. Я с этим баловался даже на нескольких тысячах файлах - и результаты "производительности" NTFS+Windows меня просто поразили. Просто FS в основном не для таких задач.