M
masto
Прохожие
У тебя было в базе 250 гигов файлов?
К этим файлам было по нескольку обращений в секунду?
Часы не поломаны были
?
Как хранить многомерные массивы?
- Автор темы the_stalker
- Дата начала
- Статус
К этим файлам было по нескольку обращений в секунду?
Часы не поломаны были
?
General Fizz
Боевой Генерал :)
- Регистрация
- 11 Апр 2007
- Сообщения
- 754
- Реакции
- 428
Совершенно верно, кроме того не надо забывать, что существуют и другие базы данных, кроме реляционных. Например базы, хранящие пары "ключ-значение" вроде Berkeley DB4. Скорость обращения и надежность у них выше, чем у реляционных. На разновидностях Беркли крутится imdb.com, gmail.com
masto
я сейчас тебе боюсь соврать, я просто прикинул на глаз, база существовала около 3-4 недель, вес ее был от 0 до ~250 и в этоу юазе было около 75 миллионов записей. Итого если я правильно посчитал это около 40 внесенных в БД записей в секунду.
Тебе ПОКАЗАТЬ базу чтоб ты поверил? Точнее 50-60 гиговый скуль дамп который от нее остался. Орегинальная база была в MySQL.
з.ы. Если вы не можете что-то сделать то это не значит что это невозможно. Если что-то не получалось у вас то это не значит что вы все делали правильно и это невозможно. "БД на файлах", MySQL, MsSQL, Oracle или Postgre... Это все форма которая заполнена содержанием по вашему усмотрению. Конечно, что-то из перечисленного работает быстрее, что-то имеет технические ограничения, но поверьте на слово, если подойти к организации БД правильно, ее размеры могут быть практически любыми. Пример: Postgre база у Yachoo сейчас является самой большой в мире БД и весит около 2тб.
я сейчас тебе боюсь соврать, я просто прикинул на глаз, база существовала около 3-4 недель, вес ее был от 0 до ~250 и в этоу юазе было около 75 миллионов записей. Итого если я правильно посчитал это около 40 внесенных в БД записей в секунду.
Тебе ПОКАЗАТЬ базу чтоб ты поверил? Точнее 50-60 гиговый скуль дамп который от нее остался. Орегинальная база была в MySQL.
з.ы. Если вы не можете что-то сделать то это не значит что это невозможно. Если что-то не получалось у вас то это не значит что вы все делали правильно и это невозможно. "БД на файлах", MySQL, MsSQL, Oracle или Postgre... Это все форма которая заполнена содержанием по вашему усмотрению. Конечно, что-то из перечисленного работает быстрее, что-то имеет технические ограничения, но поверьте на слово, если подойти к организации БД правильно, ее размеры могут быть практически любыми. Пример: Postgre база у Yachoo сейчас является самой большой в мире БД и весит около 2тб.
M
masto
Прохожие
lift, ты меня не понимаешь.
10 гигов текста в базе и 10 гигов blob'ов в базе - это абсолютно разные вещи в плане нагрузки на сервер.
и если на собственном сервачке ты ещё жить будешь, то с любого хостинга тебя попрут в 5 секунд с файлами в БД (если они не только там хранятся, но и достаточно часто отдаются).
Речь о том, что хранить файлы в БД можно, но неразумно.
Ключевое слово в моей мысли не РАЗМЕР_БД, а НАГРУЗКА_НА_СЕРВЕР.
И поверь мне на слово, сервер будет на много свободнее дышать, если в БД хранить не файл, а только путь к нему в файловой системе, поскольку с дисков файлы отдаются быстрее и "легче".
10 гигов текста в базе и 10 гигов blob'ов в базе - это абсолютно разные вещи в плане нагрузки на сервер.
и если на собственном сервачке ты ещё жить будешь, то с любого хостинга тебя попрут в 5 секунд с файлами в БД (если они не только там хранятся, но и достаточно часто отдаются).
Верю, но нетолько твоему слову но и собственному опыту, благо в своё время тусовался с достаточно крутыми ораклистами и видел результаты их работы.
Речь о том, что хранить файлы в БД можно, но неразумно.
Ключевое слово в моей мысли не РАЗМЕР_БД, а НАГРУЗКА_НА_СЕРВЕР.
И поверь мне на слово, сервер будет на много свободнее дышать, если в БД хранить не файл, а только путь к нему в файловой системе, поскольку с дисков файлы отдаются быстрее и "легче".
masto
В принцепе касательно именно хранения файлов и именно в mysql то тут на форуме проскакивал конкретный пример про то как у человека на булке аттачи хранились в БД, около 9 гигов. Форум работал но с дикими тормозами. Тут я с тобой согласен. Но это всетаки узкоспециализированный пример. Просто в базе под аттачи была 1 таблица и тут имеет место даже не вопрос о том что 9 гигов было в 1 базе а что 9 гигов было в 1 таблице. Тут я полностью согласен с тем что это бред. Но с другой стороны сделай модуль к булке и раздели таблицу с аттачами хотя бы по первым буквам названия файлов и ты получиш вместо 1 таблици на 9 гигов минимум 36 таблиц в среднем по 250 мб всего. И тормозов не будет. Более того их не будет и если суммарное количество файлов в базе увеличиться еще в несколько раз. Грубо говоря до тех пор пока размер 1 таблици снова не достигнет 9 гигов. Согласен?
Тоесть я хочу сказать что проблемы бывают только когда к решению вопросов неправильный подход. Тогда от 15 гиговой базы для булки умирает от нагрузки сервер из-за того что в ней хранитяться аттачи и летает многосотгиговая база если ее структура изначально рассчитана под такие размеры.
Тут я с тобой согласен. Именно это я и имел ввиду под словами о структуре базы.
В принцепе касательно именно хранения файлов и именно в mysql то тут на форуме проскакивал конкретный пример про то как у человека на булке аттачи хранились в БД, около 9 гигов. Форум работал но с дикими тормозами. Тут я с тобой согласен. Но это всетаки узкоспециализированный пример. Просто в базе под аттачи была 1 таблица и тут имеет место даже не вопрос о том что 9 гигов было в 1 базе а что 9 гигов было в 1 таблице. Тут я полностью согласен с тем что это бред. Но с другой стороны сделай модуль к булке и раздели таблицу с аттачами хотя бы по первым буквам названия файлов и ты получиш вместо 1 таблици на 9 гигов минимум 36 таблиц в среднем по 250 мб всего. И тормозов не будет. Более того их не будет и если суммарное количество файлов в базе увеличиться еще в несколько раз. Грубо говоря до тех пор пока размер 1 таблици снова не достигнет 9 гигов. Согласен?
тут ты прав отчасти. точнее ты прав только до тех пор пока количество файлов вообще может храниться в выбраной файловой системе. Для линевой файловой системы exp2 хранение пары миллионов картинок структурировано будет проблематично на уровне фс. В фат32 будет та же проблема. в нтфс и exp3 это же будет и при количестве несколько миллионов... В то же время хранение этих миллионов файлов в хорошо структурированой БД снимер эту проблему.
Тоесть я хочу сказать что проблемы бывают только когда к решению вопросов неправильный подход. Тогда от 15 гиговой базы для булки умирает от нагрузки сервер из-за того что в ней хранитяться аттачи и летает многосотгиговая база если ее структура изначально рассчитана под такие размеры.
M
masto
Прохожие
хранение файлов вообще не представляет ни какой проблемы - есть дисковые массивы, NAS, распределённые файловые системы.
Теперь что такое БД - это файл на диске, в котором определённым образом записанны различные данные.
Чтоб отдать файл, хранящийся в БД надо сначала окрыть файл самой БД, найти в нём нужные данные и затем отдать клиенту.
И как ты не оптимизируй БД, файл напрямую с диска всё равно отдавать быстрее и легче по нагрузке.
О том что многое зависит от архитетуры ни кто и не спорит, просто есть вещи, которые проще/лучше делать не трогая БД, хотя БД это и позволяет.
PS пример про 9 гигов приводил как раз я
PPS что-то мы отклонилисть от сабжа
Теперь что такое БД - это файл на диске, в котором определённым образом записанны различные данные.
Чтоб отдать файл, хранящийся в БД надо сначала окрыть файл самой БД, найти в нём нужные данные и затем отдать клиенту.
И как ты не оптимизируй БД, файл напрямую с диска всё равно отдавать быстрее и легче по нагрузке.
О том что многое зависит от архитетуры ни кто и не спорит, просто есть вещи, которые проще/лучше делать не трогая БД, хотя БД это и позволяет.
PS пример про 9 гигов приводил как раз я
PPS что-то мы отклонилисть от сабжа
У Yahoo не терабайт на постгре, петабайт.
Единственая проблема при хостинге файлов в ДБ это то, что к ним обращаешся через сокет.
То есть если файлы находяться на другом сервере, то размица будет не велика между NFS и MySQL.
Но сайт может быть всё таки медленей.
Потому, что скрипты типа attach.php обычно не умеют отвечать на запросы партиал или хедер и в ответ дают полные файл опять и опять когда достаточно сказать, что файл не модифицирован или отдать последние 10% файла.
Поэтому не следует гнать на мускл. Все базы реализует базовые алгоритны поиска примерно одинаково. И возможно мускл может находить маленькие файлы внутри таблицы быстрей чем это делает файловая система.
Например мусклу не нужно открывать и закрывать файл для каждой маленькой картинки. А обращения к ядру это его блокировки, которые могут сказываться на производительности всего сервера.
Единственая проблема при хостинге файлов в ДБ это то, что к ним обращаешся через сокет.
То есть если файлы находяться на другом сервере, то размица будет не велика между NFS и MySQL.
Но сайт может быть всё таки медленей.
Потому, что скрипты типа attach.php обычно не умеют отвечать на запросы партиал или хедер и в ответ дают полные файл опять и опять когда достаточно сказать, что файл не модифицирован или отдать последние 10% файла.
Поэтому не следует гнать на мускл. Все базы реализует базовые алгоритны поиска примерно одинаково. И возможно мускл может находить маленькие файлы внутри таблицы быстрей чем это делает файловая система.
Например мусклу не нужно открывать и закрывать файл для каждой маленькой картинки. А обращения к ядру это его блокировки, которые могут сказываться на производительности всего сервера.
venetu
Мой дом здесь!
- Регистрация
- 28 Мар 2007
- Сообщения
- 745
- Реакции
- 273
Ура! Возвращаемся к сабжу
Короче я данных сейчас не приведу, но по опыту 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 по скорости далеко позади. Сериалайз - быстро, 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!
Jeurey
Хранитель порядка
- Регистрация
- 13 Сен 2006
- Сообщения
- 419
- Реакции
- 614
Ну на тему скорости парсинга XML уже давно разговоры идут.
Только вот когда пишут - не всегда понимают, что обращение к строке может быть реализовано по-разному... в качестве примера:
Как быстрее добраться до содержимого тега <content> зная только имя? Воот - и я о том же. Плюс- есть ведь и нативные сишные парсеры, которые можно заюзать из пыха
Хотя, конечно, venetu, доля логики есть в твоих словах. Вообще - все нужно смотреть от задачи... Если составлять индексы в xml, а сами данные хранить в текстовых файлах - будет еще быстрее любой СУБД, при ряде оганичений
ЗЫ: n42, а кто тебе сказал, что у них БД одна? И что машина одна... и кластер один... и ДЦ один?
Только вот когда пишут - не всегда понимают, что обращение к строке может быть реализовано по-разному... в качестве примера:
Как быстрее добраться до содержимого тега <content> зная только имя? Воот - и я о том же. Плюс- есть ведь и нативные сишные парсеры, которые можно заюзать из пыха
Хотя, конечно, venetu, доля логики есть в твоих словах. Вообще - все нужно смотреть от задачи... Если составлять индексы в xml, а сами данные хранить в текстовых файлах - будет еще быстрее любой СУБД, при ряде оганичений
ЗЫ: n42, а кто тебе сказал, что у них БД одна? И что машина одна... и кластер один... и ДЦ один?
- Статус