|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Добрый день. Есть необходимость хранить большие объемы файлов (картинок) размером до 100 kb из ограниченного (до тысяч) списка источников. Источники объединяются в группы. Файлы привязаны ко времени занесения в базу. Выбираться данные будут по источнику за указанный период. Посоветуйте плз, как организовать это хозяйство. Рабочая версия - кассандра, но картина в голове не выстраивается. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2013, 11:23 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Загружай картинки в BLOBы. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2013, 13:55 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Блобы в смысле в обычной таблице РСУБД? Этих блобов может быть достаточно много. Теоретически рост может быть десятки мегабайт в секунду. И соотношение записи к чтению я вижу порядка 90/10, а то и больше. Честно говоря, до сих пор использовал БД "традиционным" способов и не набивал их так бинарями. Не очень себе представляю, как она себя поведет. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2013, 16:07 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
DeviderЭтих блобов может быть достаточно много. Теоретически рост может быть десятки мегабайт в секунду. Хреновая у тебя теория. На десятки мегабайт в секунду не хватит пропускной способности сети. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2013, 16:13 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovDeviderЭтих блобов может быть достаточно много. Теоретически рост может быть десятки мегабайт в секунду. Хреновая у тебя теория. На десятки мегабайт в секунду не хватит пропускной способности сети. Уж кто бы говорил! В-обсчем, учись, студент: wide area networks bitrate local area networks bitrate wireless networks bitrate ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2013, 20:26 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
sphinx_mvВ-обсчем, учись, студент: Ты эта... Начни уже отличать мегабиты от мегабайтов. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2013, 20:47 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovsphinx_mvВ-обсчем, учись, студент: Ты эта... Начни уже отличать мегабиты от мегабайтов. Маразм крепчает? А просто поделить (на калькуляторе, если по другому не получается) 100, ладно... пусть не 100, а хотя бы 80 мегабит в секунду ( "fast ethernet" , который 100BASE-TX, 1995 год) на 8 бит (которые в одном байте) не судьба? А еще бывает и 1000 мегабит в секунду ( gigabit ethernet , 1998 год)... И это - далеко не самые большие цифры даже для "ширпотреба". Кстати, если кто-то почему-то "не заметил" - в табличках по ранее приведенной ссылке даже есть колонка "байты в секунду"... В-обсчем, скромные "десятки мегабайт в секунду", о которых упоминал ТС, совершенно не представляют собой проблемы пропускной способности даже для сети, построенной на технолоиях прошлого века... ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2013, 23:05 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
sphinx_mvА просто поделить (на калькуляторе, если по другому не получается) 100, ладно... пусть не 100, а хотя бы 80 мегабит в секунду ("fast ethernet", который 100BASE-TX, 1995 год) на 8 бит (которые в одном байте) не судьба? Не судьба. Потому что некоторые (в отличии от...) знают не только число бит в байте, но и другие обстоятельства, делающие жизнь совсем не так радужной. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2013, 23:22 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
авторВ-обсчем, скромные "десятки мегабайт в секунду", о которых упоминал ТС, совершенно не представляют собой проблемы пропускной способности даже для сети, построенной на технолоиях прошлого века... вопрос на засыпку 100 мегабил локальная сеть это сколько мегабайт? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2013, 23:58 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovдругие обстоятельства, делающие жизнь совсем не так радужной. Погода неважнецкая, Валя из бухгалтерии отшивает, и т.д. - всё это действительно бывает. Но как это ограничивает возможности сети? Или речь идёт о какой-то конкретной сети? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2013, 23:59 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Зайцев Фёдоркак это ограничивает возможности сети? Данные в БД передаются не на Ethernet уровне. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2013, 00:08 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovsphinx_mvА просто поделить (на калькуляторе, если по другому не получается) 100, ладно... пусть не 100, а хотя бы 80 мегабит в секунду ("fast ethernet", который 100BASE-TX, 1995 год) на 8 бит (которые в одном байте) не судьба? Не судьба. Потому что некоторые (в отличии от...) знают не только число бит в байте, но и другие обстоятельства, делающие жизнь совсем не так радужной. К пропускной способности сети эти "нерадужные обстоятельства" не имеют практически никакого отношения - до "вообще" включительно! Напоминаю: про "проблемы" с передачей больших объемов "разнокалиберной" информации Вы пытаетесь рассказывать очень близко с этим связанному сотруднику телекоммуникационной компании. А у нас (даже без использования колокэйшена) клиенту в-легкую предоставляют пару сотен реальных мегабит в секунду между удаленными офисами даже не в пределах одного города. Чем клиент это "наполнит" - проблема клиента. А от нас должен быть предоставлен стабильный канал, в котором биты и байты связаны простым математическим соотношением "8-к-1". Вот такая у нас "радужная реальность", однако. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2013, 00:13 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЗайцев Фёдоркак это ограничивает возможности сети? Данные в БД передаются не на Ethernet уровне. И это полностью исключает любую возможность передавать десятки мегабайт в секунду? 5 десятков - это десятки? Народный суд запретил ТС использовать несколько сетевых интерфейсов? Я не понимаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2013, 00:23 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЗайцев Фёдоркак это ограничивает возможности сети? Данные в БД передаются не на Ethernet уровне. Поставить дисковую систему по-шустрее, не пробовали? Процессор более адекватный? Оперативной памяти достаточно? А операционную систему тюнить? ЗЫ. И как интересно стрелочки переехали с пропускной способности сети на производительность всего сервера "в сборе"... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2013, 00:34 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Зайцев ФёдорИ это полностью исключает любую возможность передавать десятки мегабайт в секунду? 5 десятков - это десятки? Десятки, десятки. Вот только для этих десятков нужен гигабитный Ethernet и протокол уровня приложения сильно плотнее чем SMB, поскольку SMB на гигабите даёт только порядка 30 мегабайт в секунду. А протоколы СУБД обычно ещё менее эффективны из-за привычки к полному квитированию. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2013, 00:39 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov это всё понятноДесятки, десятки. Вот только для этих десятков нужен гигабитный Ethernet и протокол уровня приложения сильно плотнее чем SMB, поскольку SMB на гигабите даёт только порядка 30 мегабайт в секунду. А протоколы СУБД обычно ещё менее эффективны из-за привычки к полному квитированию. , но я только что получил 45 Мб/сек. mssql server 2008, AMD A4 3400, 9999 файлов по 166Кб ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2013, 01:40 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovпоскольку SMB на гигабите даёт только порядка 30 мегабайт в секунду У меня не получается копировать файлы медленее, чем 90 Мб/сек. Надеюсь, это не признак неисправности, т.к. гарантия уже закончилась ) Получается, либо я копирую по какому-то другому протоколу, либо утверждение "...SMB на гигабите..." противоречит действительности ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2013, 02:03 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Зайцев Фёдор, 90 Мбит/c ~ 11 МегаБайт/c гордится нечем. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2013, 12:36 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Аноним321Зайцев Фёдор, 90 Мбит/c ~ 11 МегаБайт/c гордится нечем. 90 МБ, доволен? забыл как правильно пишется единица ) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2013, 12:45 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Два вопроса: 1. А у меня копирование по сети выдало 112 MB в секунду (счетчик в FAR'е). Кто больше? 2. Какое это имеет отношение к вопросу автора? Devider....Честно говоря, до сих пор использовал БД "традиционным" способов и не набивал их так бинарями. Не очень себе представляю, как она себя поведет. А какие проблемы? Информация она и есть информация. Единственное, я когда проектировал табличку с блобами складывал в отдельный tablespace и блобы хранил отдельно от данных. См. доку БД. "Как поведет" и скорость на конкретной СУБД и конкретном железе нужно наверное банально мерить. Особенно, если есть понимание о характере нагрузки. Соглашусь с Dimitry Sibiryakov, 10 мегабайт в секунду рост БД IMHO не мало - 10 МБ в сек, это 36 Gb в час, 288 Gb за 8 часовой рабочий день.... ))) Куда Вы это складывать планируете? Плюс еще redo-log'ов (в случае Oracle) не меньше (если не больше) будет создаваться. Достоинства - транзакции, поиск по индексам, надежность. Нет проблемы, что при каких либо падениях софта, останутся временные файлы на сервере, не подключенные к БД. Пока в нашей системе информация хранилась как файл + ссылка из БД - в реальных системах, которые работали годами, всегда были проблемы: часть файлов отсутствует, какие-то левые файлы и целые директории и т.д. Не критично конечно, но и не особо приятно. В БД транзакционность и таких проблем не может/не должно быть. Плюс залезть шаловливыми ручками и что-то удалить - тяжелее. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2013, 16:49 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
а точно нужна СУБД? может нужен высокопроизводительный NAS? с подключением к серверу 10GB. у нас немного другая задача - генерация отчетов для массы заказчиков в pdf и html. раскладываем по файлам. ориентировочно - 15-20млн файлов. скорость выдачи и еще по пропускной способности - Exadata, общение между ячейками до 80mbs по infiniband'у. так что... вопрос системной архитектуры... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2013, 20:34 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
AAronи еще по пропускной способности - Exadata, общение между ячейками до 80mbs по infiniband'у. до 80 gbs? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2013, 20:37 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
AAron, скорость выдачи - не дописал. количество пользователей - 200тыс+, одновременно использующих отчеты - 2-3 тыс. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2013, 20:51 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Alexander Ryndin, конечно ;)) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2013, 20:03 |
|
Хранение большого количества мелкий файлов
|
|||
---|---|---|---|
#18+
Elliptics как раз для таких целей придумано. Яндекс его пользует ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 16:09 |
|
|
start [/forum/topic.php?fid=35&fpage=7&tid=1552404]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
35ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
others: | 10ms |
total: | 151ms |
0 / 0 |