Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / NoSQL, Big Data Новый топик    Ответить
 Выбор БД для оптимального хранения мусорки json-ов  [new]
PPA
Member

Откуда: Караганда -> Липецк
Сообщений: 811
Всем привет.

Есть у меня база отдающая по хешу файла его 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 M
media-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() {} //
1 окт 14, 10:45    [16642615]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
DPH3
Member

Откуда:
Сообщений: 456
PPA,

Э, любая БД, json хранить в блобах, блобы упаковывать (lz, например) на уровне сервера приложений.
Куда уж оптимальнее )
1 окт 14, 12:59    [16643879]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
scf
Member

Откуда:
Сообщений: 1480
на mongodb посмотри
1 окт 14, 20:25    [16646982]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
PPA
Member

Откуда: Караганда -> Липецк
Сообщений: 811
scf
на mongodb посмотри


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

Если хорошо в ней разбираетесь подскажите на примере как в ней реализуется операция
1. запросить json по ключу
2. положить назад тот-же json
поправив атрибуты (в моем случае это инкремент счетчика и коррекция временной метки)
1 окт 14, 21:20    [16647191]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26508
scf
на mongodb посмотри
Для хранения 9 гиг данных? Жестоко.
1 окт 14, 23:24    [16647629]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
DPH3
Member

Откуда:
Сообщений: 456
skyANA
scf
на mongodb посмотри
Для хранения 9 гиг данных? Жестоко.

Я вот вообще не могу понять, а в чем проблема-то. С задачей справиться любая БД начиная с MySQL или Firebird
1 окт 14, 23:39    [16647681]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
PPA
Member

Откуда: Караганда -> Липецк
Сообщений: 811
DPH3
skyANA
пропущено...
Для хранения 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
2 окт 14, 07:09    [16648007]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
DirksDR
Member

Откуда: Пермь
Сообщений: 340
PPA,

Посмотри на GlobalsDB
Самая "простая хранилка key-value".
Насчет скорости должна потянуть, насчет размера БД - посмотри ограничения. На несколько серверов она не растягивается.
2 окт 14, 12:16    [16649467]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
DPH3
Member

Откуда:
Сообщений: 456
PPA
DPH3
пропущено...

Я вот вообще не могу понять, а в чем проблема-то. С задачей справиться любая БД начиная с 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



Брр, тогда давай подробнее. У тебя до 30 запросов на данные. Каждый запрос на одну запись или на несколько? Сколько всего записей выбирается в секунду? Сколько физически происходит запросов к диску, сколько seek-ов?
Судя по тому, что ты говоришь - проблема или в ужасном поведении sqllite, которая делает слишком много физических чтений или в странных VPSках, которые на самом деле, например, просто виртуалки с удаленными и перенагруженными дисками.

В общем, сначала надо разобраться, а в чем проблема - а потом уже думать про noSQL (которые тут нафиг не сдались).
У тебя локально все работает с нужной производительностью? А если вместо sqlite поставить хотя бы mysql?
2 окт 14, 14:47    [16650695]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
DPH3
Member

Откуда:
Сообщений: 456
PPA
Размер данных будет расти и как - я не могу оценить.


Размер данных будет иметь значение ближе к TB )
Ну, конечно, если не использовать EAV не по делу )
2 окт 14, 14:48    [16650701]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
PPA
Member

Откуда: Караганда -> Липецк
Сообщений: 811
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
а какой от него будет бонус?

К сообщению приложен файл. Размер - 86Kb
2 окт 14, 16:49    [16651611]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
DirksDR
Member

Откуда: Пермь
Сообщений: 340
PPA,

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

Можно будет обрабатывать запросы от пользователей параллельно.
Сейчас, похоже, они у Вас обрабатываются последовательно, т.к. и SQLite и levelDB (по крайней мере вторая)
•Only a single process (possibly multi-threaded) can access a particular database at a time.
3 окт 14, 15:23    [16656863]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для оптимального хранения мусорки json-ов  [new]
DPH3
Member

Откуда:
Сообщений: 456
PPA,

если смотреть на статистику munin, то там первым идет IO read/write.
Там хорошо видно, что в пике общее число запросов к диску доходит до 160.
При этом, если посмотреть на http://habrahabr.ru/post/164325/, то видно, что обычный hdd держит около 150 IOPS.

Т.е. задача - сильно уменьшить число обращений к диску (в первую очередь - операций позиционирования).
Задачу можно решать разными способами:
1) кэшировать все, что можно (явным образом).
2) за один раз считывать больше полезной информации.
Т.е. если запросы пользователей не совсем случайны, то можно попробовать организовать данные на диске так, что бы список из 30 хэшей лежал (скорее всего) на одной физической странице, а не на 30 разных.
Организация таблицы по какому-то ключу точно реализована в MySQL, про sqlite не знаю.
3) увеличивать количество данных на странице. Например, упаковывать блобы с json
4) увеличить число жестких дисков. Если диска два или три в raid, то уже будет полегче.
5) для каких-то данных поставить ssd
6) выстроить очередь записей и чтений, так, что бы нагрузка была равномерной )
При пиках на чтения запись можно и отложить )
И т.п.
3 окт 14, 16:42    [16657515]     Ответить | Цитировать Сообщить модератору
Все форумы / NoSQL, Big Data Ответить