Всем привет. Есть у меня база отдающая по хешу файла его mediainfo. 99% запросы идут на получения краткой информации вот такого содержания:Запрос"array":  [  {  "size":"557993421",  "tth":"A3VSWSWKCVC4N6EP2GX47OEMGT5ZL52BOS2LAHA"  }  ]Ответ"array":  [  {  "info":  {  "count_media":"99",  "count_query":"8"  },  "media":  {  "fly_audio":"1h 55mn AAC, 2.0, 128 Kbps",  "fly_audio_br":"128",  "fly_video":"AVC, 512 Kbps, 25.000 fps",  "fly_xy":"640x360"  },  "size":"557993421",  "tth":"A3VSWSWKCVC4N6EP2GX47OEMGT5ZL52BOS2LAHA"  }  ]Иногда пользователь может захотеть получить весь набор атрибутов файла тут данных намного больше:

 

{  "media":  {  "fly_audio":"4mn 7s MPEG, 2.0, 128 Kbps",  "fly_audio_br":128  },  "media-ext":  {  "audio":  {  "channel-all":  {  "BitRate":"128000",  "BitRate_Mode":"CBR",  "Channel(s)":"2",  "Codec":"MPA1L3",  "Codec_Profile":"Joint stereo",  "Compression_Mode":"Lossy",  "Count":"222",  "Duration":"248398",  "Format":"MPEG Audio",  "Format_Commercial":"MPEG Audio",  "Format_Profile":"Layer 3",  "Format_Settings":"Joint stereo / MS Stereo",  "Format_Settings_Mode":"Joint stereo",  "Format_Settings_ModeExtension":"MS Stereo",  "Format_Version":"Version 1",  "FrameCount":"9509",  "Inform":"Format : MPEG Audio\r\nFormat version : Version 1\r\nFormat profile : Layer 3\r\nMode : Joint stereo\r\nMode extension : MS Stereo\r\nDuration : 4mn 8s\r\nBit rate mode : Constant\r\nBit rate : 128 Kbps\r\nChannel(s) : 2 channels\r\nSampling rate : 44.1 KHz\r\nCompression mode : Lossy\r\nStream size : 3.78 MiB (100%)\r\n",  "InternetMediaType":"audio/mpeg",  "SamplingCount":"10954368",  "SamplingRate":"44100",  "StreamCount":"1",  "StreamKind":"Audio",  "StreamKindID":"0",  "StreamSize":"3965178"  }  },  "general":  {  "Album":"Movin' Melodies",  "AudioCount":"1",  "Audio_Codec_List":"MPEG-1 Audio layer 3",  "Audio_Format_List":"MPEG Audio",  "Audio_Format_WithHint_List":"MPEG Audio",  "Codec":"MPEG Audio",  "Count":"284",  "Duration":"247823",  "FileExtension":"mp3",  "Format":"MPEG Audio",  "Format_Commercial":"MPEG Audio",  "Inform":"Format : MPEG Audio\r\nFile size : 3.78 MiB\r\nDuration : 4mn 7s\r\nAlbum : Movin' Melodies\r\nTrack name : Underwater World\r\nPerformer : ATB\r\n",  "InternetMediaType":"audio/mpeg",  "OverallBitRate":"128000",  "OverallBitRate_Mode":"CBR",  "Performer":"ATB",  "StreamCount":"1",  "StreamKind":"General",  "StreamKindID":"0",  "StreamSize":"128",  "Title":"Underwater World",  "Track":"Underwater World"  }  },  "size":"3965306",  "tth":"6ZJCIER2ML6DDD2MKHN6CLBT5FA4DP2RQRUOI4Q"  }

Сейчас вся информация нормализованно лежит в бд sqlite в виде EAV модели. и размер файла достиг 8.8 гиг - это напрягает число записейв основной таблице~12 млн.для которых есть расширенная инфа1.1 млн Решил провести эксперимент и перетащил редко-используемую вторую часть в LevelDB в итоге sqlite файл похудел до 1.3 гига Размеры levelDB с компрессией и без оказались такимиразмерmedia-db.leveldb4371 Mmedia-db-compress.leveldb1908 M Пока в плане произвести такую миграцию... Может порекомендуйте более другое оптимальное по диску хранилище для решения подобной задачи Цель

• быстро возвращать краткую информацию по файлам текущая нагрузка 5-30 запросов в секунду (на вход массив ключей)
Увеличивать счетчики и менять временную метку для файлов из пункта 1 в sql я делаю так update fly_file set count_query=count_query+1, last_date=strftime('%s','now','localtime') where id in(?,?,...) компактно хранить json с расширенной информацией mediainfo и отдавать по запросу - можно даже не очень быстро (т.к. такие запросы намного реже идут - 100-200 в сутки) в идеале может вообще для второй части можно обойтись без БД и скидывать инфу в виде файлов с уникальным именем но тут я не тестировал вижу возможные проблемы на лимит по inode и размер каталога. зато реплика будет делаться легко...

-- ~PPA() {} //

scfна mongodb посмотри

Много слышал про нее, но никогда не работал.
а она умеет сжатие прозрачное делать как levelDB?
также у меня пока 32 битный выделенный сервер.
читал что есть ограничение на размер базы в этом случае - 2г т.к. используется memory-mapped

Если хорошо в ней разбираетесь подскажите на примере как в ней реализуется операция
1. запросить json по ключу
2. положить назад тот-же json
поправив атрибуты (в моем случае это инкремент счетчика и коррекция временной метки)

DPH3skyANAпропущено...
Для хранения 9 гиг данных? Жестоко.
Я вот вообще не могу понять, а в чем проблема-то. С задачей справиться любая БД начиная с MySQL или Firebird

Проблема у меня с хранением.
Размер данных будет расти и как - я не могу оценить.
у меня сервер мелкий http на С++ под Linux
для хранилища использую sqlite, но он не всегда справляется.
я перебрал разные VPS-ки нагрузку тянет только digitalocean c SSD винтами.
но база сильно пухнет а в SSD диски дорогие - я и хотел унести львиную долю контента в noSQL
также она пользователям обычно не требуется - можно и тормознее отдавать.

Для этого купил выделенный сервер у kimsufi
KS-2 Atom™ N2800 2c / 4t 1.86 GHz+ 4 GB 1 TB
думал он потянет все как есть в sqlite - но нет.
полную нагрузку он не тянет и начинает тупить база отдавая ответы через 50-100 мс (digital ocean - 1-2ms)
вот я пришел в noSQL форум :)
т.к. у меня задача - простая хранилка key-value

DPH3,

У меня sqlite и сейчас работает терпимо - я нашел VPS на SSD в Нидерландах она тянет
исходя из этого думаю, что проблема в медленных винтах.
но у меня сервер 30Gb всего и скоро закончится - нужно повышать тариф.

юзера шлют запросы пачками по мере "листания" списка файлов в программе.

тут я описывал как работает обмен в начале разработки этой всей штуки
http://www.flylinkdc.ru/2013/01/blog-post.html

Каждый юзер в нормальном режиме шлет от 5 до 40 ID-шек в запросе
назад возвращается минимальная медиа-информация по этим ID (качество звука - видео и разрешение)
sqlite делает выборку одну выборку из простой плоской таблицы (рис 1) по этому массиву ID-шек
потом делает апдейт по нему-же увеличивая счетчики и временные метки.

если бы sqlite умел returning как oracle я бы все в один апдейт засунул :)

пачку в 10 записей он отрабатывает ~ за 2-10 мсек
(наверно в буфера попадает - я для них выделил почти всю память сервера) вот его нагрузка кстати
http://146.185.183.102/munin/localdomain/localhost.localdomain/index.html
про seek дисков незнаю - не умею их смотреть :(

Выборка расширенной части атрибутов (которые хранятся в EAV) вообще делается очень редко (всего несколько раз в день)
к ней обращаются уже по правой кнопке на конкретном файле
т.е. получается слишком жирно для этого держать эти данные на SSD

и эта почти-мертвая таблица жрет 8 гиг - а выкинуть жалко

пока делаю так, что основная таблица остается в sqlite
в ней я могу быстро делать выборки и делать апдейты
а дочерняя расширенная информация выносится в levelDB с прозрачным сжатием
это даст время протянуть на SSD еще некоторое время :)

на levelDB я уже мигрировал в клиентской части
получается быстрее sqlite на 30%
http://www.flylinkdc.ru/2013/07/flylinkdc-google-leveldb.html

mysql не пробовал - не уверен что он будет быстрее sqlite
а какой от него будет бонус?