Уметь подгружать с диска BLOBы, соответствующие конкретной категории. С хорошей производительностью.

т.е. вся категория при этом будет целиком в памяти, вместе с блобами? Если так, то лучше делать самому.

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

Никак нет. Мне более чем достаточно итеративного доступа, когда в память единовременно грузится только 1 запись.

Ещё одна проблема — одной записи может соответствовать несколько категорий.

Не льсти себе - это даже и близко не bigdata.

Я пытался сделать это через SQLite, подгружая BLOBы каждой категории через список IDшек, относящихся к ней (создавая временную табличку в памяти).

Из этой фразы даже не понятно, хранятся блобы в sqlite или ФС.

man mmap. Он по-умолчанию в Линуксе ленивый, поэтому пока страничку не тронешь, её в памяти нет. Индекс сам придумай. Ну и там всякие madvise можно делать.

Если данные не статичны, то нагугли какой-нибудь простенький сишечный buddy allocator и используй его на области замапленного файла.

Ещё одна проблема — одной записи может соответствовать несколько категорий.

вот теперь нифига не понятно, т.е. не ясна структура твоих данных.

GridFS? Swift?

Разумеется, в SQLITE.

CREATE TABLE 'docBlobs' ('docId' INTEGER, 'featureIndexes' BLOB, 'featureWeights' BLOB );

CREATE INDEX 'docIdIndex_docBlobs' ON 'docBlobs' ('docId' ASC);

36Гб в sqlite… Редкое извращение :)

Есть куча текстов, из котороых выдраны некоторые фичи (для каждого текста создаётся 2 BLOBа: индексы этих фич - и их веса в тексте).

Каждому тексту присвоен 1 или более тег (это и есть категорий.)

Здесь нет списка категорий. Впрочем, уже можно сказать, что два блоба в одной строке таблицы - решение сомнительное.

Всё лучше, чем создавать миллион файлов, n'est-ce pas?

Списки документов, относящиеся к каждой категории, я храню в памяти, они там вполне помещаются.

Не знаю насчет остальных, а для меня твоя задача так и осталась невнятной.

Всё лучше, чем создавать миллион файлов, n'est-ce pas?

Не факт даже в случае однопоточной работы. И очевидно хуже — в случае многопоточной.

В sqlite, вообще, ключевое слово — «lite».

Есть куча текстов, из котороых выдраны некоторые фичи (для каждого текста создаётся 2 BLOBа: индексы этих фич - и их веса в тексте).

выходит, что доступ к блобам относительно рандомный, потому совсем хорошо не сделаешь. Ориентироваться стоит на скорость линейного чтения всех данных с диска. Для твоих объёмов это около 4-5 минут на типичном hdd. Если SQLite укладывается в это время, то стоит забить.

Либо стоит срараться сделать всю работу за один проход по блобам.

Пока что доступ к 10K случайных документов из 1M получается примерно столько же по времени, сколько и чтение всех документов подряд.

Около 8 минут.

Для 10к можно взять SSD, будет считываться за секунды.

Можно, разумеется. Только вряд ли заказчики внезапно на SSD перейдут.

А для типичного hdd это пара минут. Т.е. если по 10к грузить, то есть смысл избавиться от SQLite и сделать всё на k/v хранилище типа bdb, gdbm или самописном.

Можете ли что-нибудь посоветовать?

А почему ещё никто не посоветовал Berkeley DB? Или какое-нибудь другое key-value хранилище. Tokyo Cabinet, Kyoto Cabinet считаются быстрыми.

Всё лучше, чем создавать миллион файлов

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

мне просто интересно, чем лучше?

у ФС большой оверхед на мелкие файлы, медленные операции доступа, засорение кэша от 1M ненужных объектов (ФС она почти одна на всё).

хранение большого кол-ва блобов/клобов в базе данных, априори не правильная архитектура приложения.

это какой-то неправильный обобщённый стереотип, выросший из историй хранения больших блобов (мегабайты и более) в рСУБД разработчиками из мира офтопика.

индексы и прочие метаданные хранить как и прежде в sqlite, «blob» ы вынести в ФС как обычные файлы или в key-value базу а-ля berkeley db,gdbm/ndbm.

у ФС большой оверхед на мелкие файлы, медленные операции доступа, засорение кэша от 1M ненужных объектов (ФС она почти одна на всё).

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

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


при чём тут офтопик не понял в принципе.

Около 8 минут.

Что-то многовато. Я из любопытства проверил. SQLite, 1M записей, в записи ид и 40к рандомного блоба. Диск какой-то совсем обычный.

Выбираем 10к записей со случайным ид:

real	1m43.405s
user	0m1.528s
sys	0m1.404s

10к записей последовательно:

real	0m1.794s
user	0m0.836s
sys	0m0.584s

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

дававай не будешь заниматься обобщением особенностей работы с блобами какой-то определённой рСУБД на все БД? Твои обобщения неверны даже среди реляционок, не говоря уже про KV БД.

http://stackoverflow.com/questions/446358/storing-a-large-number-of-images

если файлуха прогнется то надо вместо файловой системы крутить некое подобие некое подобие vfs (для примера так хранять игры свои ресурсы) но это хорошо для readonly систем

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

10к записей, сброшенный дисковый кеш и случайный доступ:

real	0m26.659s
user	0m0.008s
sys	0m0.236s

Кешированное:

real	0m0.119s
user	0m0.008s
sys	0m0.112s

как-то слишком бодро вышло для обычного диска и случайного доступа. Мб 10к выбираешь не из всего 1M? Обычный диск это примерно 100 IOPS, т.е. нормальный порядок на 40гб будет около 100 сек.

LMDB, если чтение сильно превышает запись. Впрочем, и на запись при определенных конфигурациях быстрее аналогов.

как-то слишком бодро вышло для обычного диска и случайного доступа.

разрыв шаблона. надо же, но ты продолжай хранить блобы в бд, а не править архитектуру.

такого же эффекта добивались храня по файлово в /u/id % 1000/id в рейзер 3.6, тоже теоретики сидели и доказывали, как хорошо хранить в бд, нет чтоб потратить 30 минут времени на проверку своего теоретизма...

Мб 10к выбираешь не из всего 1M?

        for (i=0; i<10000; i++) {
                uint64_t off;

                off = (rand() % 1000000) * sizeof(buf);
                fseek(f, off, SEEK_SET);
                fread(buf, 1, sizeof(buf), f);
        }

нормальный порядок на 40гб будет около 100 сек.

Я вчера поленился перепроверить, щас с утра позапускал несколько раз. Время слегка плавает, но до 100 сек не дотягивает. Вот самый медленный запуск:

$ sudo echo 3 > /proc/sys/vm/drop_caches 
$ time ./fetch_test 

real	0m42.409s
user	0m0.004s
sys	0m0.340s
$ time ./fetch_test 

real	0m0.131s
user	0m0.008s
sys	0m0.124s

Возможно, это префетчинг помогает?

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

{ категория:[(имя файла, смещение блоба), ...], ... }

ЗЫ можно даже сразу сгруппировать по файлам:

{ категория: {имя файла: [смещение блоба, ...], ... }, ... }

fseek(f, off, SEEK_SET);

Ха-ха. Я _FILE_OFFSET_BITS=64 выставил, а fseek оставил 32-битный. Надо fseeko

real	1m18.051s
user	0m0.028s
sys	0m0.392s

78 секунд. Ну, недалеко от 100.

Кешированное:

real	0m0.133s
user	0m0.000s
sys	0m0.132s

78 секунд. Ну, недалеко от 100.

около 120-130 IOPSов, уже нормально, подходит под хороший обычный диск

разрыв шаблона. надо же, но ты продолжай хранить блобы в бд, а не править архитектуру.

ты какой-то тупой. Попробуй сначала разобраться о чём здесь вообще разговор.

У меня нечто подобное сделано для хранения данных с железки. Там категорий мало, поэтому я тупо в id отвел несколько бит под категорию. В итоге получилась таблица id, blob которая лежит в SQLite. Блобы жмутся, поэтому у них у всех разная длина, а городить самописный формат мне было лень. Вариант много файлов рассматривался, но очень неудобно для пользователя. Так одно измерение — одно файло, таскай как хош.

Храни в файловой системе. Имя файла - ID блоба, по директории на категорию, хардлинк если категорий больше одной. Делается это быстро и просто. Если будет тормозить - тогда начнёшь оптимизировать. Нормальные ФС (ext3, ext4, reiserfs) без проблем держат миллионы файлов даже в одной директории.

Есть проблема: эта доброштука должна неплохо работать и под Windows, а NTFS с миллиона файлов таки начинает тормозить.

Быстрое локальное блобохранилище

только я прочитал «баблохранилище»?

Нормальные ФС (ext3, ext4, reiserfs) без проблем держат миллионы файлов даже в одной директории.

ext3

Ню-ню.

Я проводил тесты: http://legolegs.livejournal.com/1815.html