Как хранить многомерные массивы?

Статус
В этой теме нельзя размещать новые ответы.
Хорош гнать про 10 гигов.
У тебя было в базе 250 гигов файлов?
К этим файлам было по нескольку обращений в секунду?
Часы не поломаны были :)?
 
...Что касается SQL - надо трезво оценивать когда его стоит использовать, а когда нет и почему.

Совершенно верно, кроме того не надо забывать, что существуют и другие базы данных, кроме реляционных. Например базы, хранящие пары "ключ-значение" вроде Berkeley DB4. Скорость обращения и надежность у них выше, чем у реляционных. На разновидностях Беркли крутится imdb.com, gmail.com
 
masto
я сейчас тебе боюсь соврать, я просто прикинул на глаз, база существовала около 3-4 недель, вес ее был от 0 до ~250 и в этоу юазе было около 75 миллионов записей. Итого если я правильно посчитал это около 40 внесенных в БД записей в секунду.
Тебе ПОКАЗАТЬ базу чтоб ты поверил? Точнее 50-60 гиговый скуль дамп который от нее остался. Орегинальная база была в MySQL.
з.ы. Если вы не можете что-то сделать то это не значит что это невозможно. Если что-то не получалось у вас то это не значит что вы все делали правильно и это невозможно. "БД на файлах", MySQL, MsSQL, Oracle или Postgre... Это все форма которая заполнена содержанием по вашему усмотрению. Конечно, что-то из перечисленного работает быстрее, что-то имеет технические ограничения, но поверьте на слово, если подойти к организации БД правильно, ее размеры могут быть практически любыми. Пример: Postgre база у Yachoo сейчас является самой большой в мире БД и весит около 2тб.
 
lift, ты меня не понимаешь.
10 гигов текста в базе и 10 гигов blob'ов в базе - это абсолютно разные вещи в плане нагрузки на сервер.
и если на собственном сервачке ты ещё жить будешь, то с любого хостинга тебя попрут в 5 секунд с файлами в БД (если они не только там хранятся, но и достаточно часто отдаются).

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

Ключевое слово в моей мысли не РАЗМЕР_БД, а НАГРУЗКА_НА_СЕРВЕР.
И поверь мне на слово, сервер будет на много свободнее дышать, если в БД хранить не файл, а только путь к нему в файловой системе, поскольку с дисков файлы отдаются быстрее и "легче".
 
masto
Ключевое слово в моей мысли не РАЗМЕР_БД, а НАГРУЗКА_НА_СЕРВЕР.
Тут я с тобой согласен. Именно это я и имел ввиду под словами о структуре базы.
В принцепе касательно именно хранения файлов и именно в mysql то тут на форуме проскакивал конкретный пример про то как у человека на булке аттачи хранились в БД, около 9 гигов. Форум работал но с дикими тормозами. Тут я с тобой согласен. Но это всетаки узкоспециализированный пример. Просто в базе под аттачи была 1 таблица и тут имеет место даже не вопрос о том что 9 гигов было в 1 базе а что 9 гигов было в 1 таблице. Тут я полностью согласен с тем что это бред. Но с другой стороны сделай модуль к булке и раздели таблицу с аттачами хотя бы по первым буквам названия файлов и ты получиш вместо 1 таблици на 9 гигов минимум 36 таблиц в среднем по 250 мб всего. И тормозов не будет. Более того их не будет и если суммарное количество файлов в базе увеличиться еще в несколько раз. Грубо говоря до тех пор пока размер 1 таблици снова не достигнет 9 гигов. Согласен?
И поверь мне на слово, сервер будет на много свободнее дышать, если в БД хранить не файл, а только путь к нему в файловой системе, поскольку с дисков файлы отдаются быстрее и "легче".
тут ты прав отчасти. точнее ты прав только до тех пор пока количество файлов вообще может храниться в выбраной файловой системе. Для линевой файловой системы exp2 хранение пары миллионов картинок структурировано будет проблематично на уровне фс. В фат32 будет та же проблема. в нтфс и exp3 это же будет и при количестве несколько миллионов... В то же время хранение этих миллионов файлов в хорошо структурированой БД снимер эту проблему.
Тоесть я хочу сказать что проблемы бывают только когда к решению вопросов неправильный подход. Тогда от 15 гиговой базы для булки умирает от нагрузки сервер из-за того что в ней хранитяться аттачи и летает многосотгиговая база если ее структура изначально рассчитана под такие размеры.
 
хранение файлов вообще не представляет ни какой проблемы - есть дисковые массивы, NAS, распределённые файловые системы.

Теперь что такое БД - это файл на диске, в котором определённым образом записанны различные данные.
Чтоб отдать файл, хранящийся в БД надо сначала окрыть файл самой БД, найти в нём нужные данные и затем отдать клиенту.
И как ты не оптимизируй БД, файл напрямую с диска всё равно отдавать быстрее и легче по нагрузке.

О том что многое зависит от архитетуры ни кто и не спорит, просто есть вещи, которые проще/лучше делать не трогая БД, хотя БД это и позволяет.

PS пример про 9 гигов приводил как раз я :)

PPS что-то мы отклонилисть от сабжа :ah:
 
Текс...
Может, таки лучше XML? Для много-много-мерных структур данных?

Кто возьмется профилирование провести с разными XML-парсерами? :)
 
У Yahoo не терабайт на постгре, петабайт.

Единственая проблема при хостинге файлов в ДБ это то, что к ним обращаешся через сокет.

То есть если файлы находяться на другом сервере, то размица будет не велика между NFS и MySQL.

Но сайт может быть всё таки медленей.

Потому, что скрипты типа attach.php обычно не умеют отвечать на запросы партиал или хедер и в ответ дают полные файл опять и опять когда достаточно сказать, что файл не модифицирован или отдать последние 10% файла.

Поэтому не следует гнать на мускл. Все базы реализует базовые алгоритны поиска примерно одинаково. И возможно мускл может находить маленькие файлы внутри таблицы быстрей чем это делает файловая система.

Например мусклу не нужно открывать и закрывать файл для каждой маленькой картинки. А обращения к ядру это его блокировки, которые могут сказываться на производительности всего сервера.
 
Ура! Возвращаемся к сабжу :)

Текс...
Может, таки лучше XML? Для много-много-мерных структур данных?

Короче я данных сейчас не приведу, но по опыту XML по скорости далеко позади. Сериалайз - быстро, json - сложно сказать, т.к. парсеры все самописные, но в принципе если не маньячить то тоже будет явно намного быстрее xml. Ну а еще довольно быстро будет генерить php-код, который инициализирует массив. Т.е. скидывать в файл (или базу - привет офтоперам!:) ) нечто типа такого:

$arr=array(1,array(1,2,array(3,4),'txt','key' => 'txt2'),5,6);

а потом это дело инклудить или eval'ить.

Да, знаю, eval сyкамедленный, но он тут вызывается один раз, а дальше нативный php-парсер быстро наверстывает упущенную скорость. :)

Вот сравнить по скорости эту штуку с serialize было бы интересно.. Но что-то мне кажется, что serialize будет все равно быстрее всего! :) Ибо самый короткий путь - прямой!

Я нисколечни не гоню на XML, это очень прикольная и полезная штука, но для своей области.. Опять же, если б проигрыш по скорости, памяти, размеру и т.д. был не такой большой, я бы тоже ратовал за ее использование везде, где можно. Но если задача сохранить из php массив и потом достать его же обратно в php - то тут xml будет явно из пушки по воробьям..

Я за serialize!
 
Ну на тему скорости парсинга XML уже давно разговоры идут.

Только вот когда пишут - не всегда понимают, что обращение к строке может быть реализовано по-разному... в качестве примера:

<root>
<item id="1">
<name>Sample</name>
<content>Sampla content</content>
</item>
</root>


<root>
<item id="1" name="Sample">
<content>Sampla content</content>
</item>
</root>

Как быстрее добраться до содержимого тега <content> зная только имя? Воот - и я о том же. Плюс- есть ведь и нативные сишные парсеры, которые можно заюзать из пыха :)

Хотя, конечно, venetu, доля логики есть в твоих словах. Вообще - все нужно смотреть от задачи... Если составлять индексы в xml, а сами данные хранить в текстовых файлах - будет еще быстрее любой СУБД, при ряде оганичений ;)

ЗЫ: n42, а кто тебе сказал, что у них БД одна? И что машина одна... и кластер один... и ДЦ один? :D
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху