Полная Версия: Скачивание больших файлов из БД PostgreSQL
| Цитата (AllesKlar @ 21.12.2017 - 13:00) |
| Если у меня CDN картинок, не превышающих 10 мб, то база (специфичная, НЕ реляционная) - отличное решение. |
интересно чем? Какой профит по сравнению с отдачей легковесными вебсерверами + ФС ?
| Цитата (Xakep @ 21.12.2017 - 14:41) |
| Это не моя инициатива и "хотелка". Это конкретное требование заказчика. |
прогресс загрузки не работает, докачка не поддерживается, каждая загрузка откусывает php воркер на длительная время, пока не отдаст файл, множество параллельных закачек имеют все шансы положить сервак, количество воркеов для обслуживания остальных - обычных запросов, сокращается, нагрузка на сервер растёт .. кхм и ради чего?
Хотя бы поинтересуйся у заказчика, чем обоснована его "хотелка", и в курсе ли он какие минусы она несёт?
| Цитата (Xakep @ 21.12.2017 - 10:41) |
| Это не моя инициатива и "хотелка". Это конкретное требование заказчика. |
Это звучит неубедительно. Я писал про компетентность. Есть знаменитый ролик про семь параллельных красных линий, две из которых перпендикулярны, три зеленым цветом и одну в виде котенка. Эта задача, как ни странно, имеет решение, однако компетентность исполнителя заключается не в том, что он умеет вырезать гланды через задницу, а в том, чтобы убедить заказчика в ущербности такого метода.
Присоединюсь к вопросу vagrand:
Присоединюсь к вопросу vagrand:
| Цитата (vagrand @ 21.12.2017 - 17:05) |
| Реальный пример подскажите, где обосновано хранить файлы в БД |
Лично я не могу придумать. Репликации... Так выгоднее организовать отдельный сервер под ФС, чем растаскивать базу. Портабл-версия БД для обменов... Но никакой сложности обновить файлы как таковые, это менее геморно, чем обновлять терабайтные таблицы. Безопасность... Так и файлы можно зашифровать. Не знаю.
Единственно чем можно попытать оправдать сие (до чего я додумался) - уже готовая база данных. Но это тоже слабое оправдание, на языке профессионалов называется "костыль". Исправить это недоразумение проще, чем обрекать приложение на кучу проблем в будущем.
Просвети, может мы действительно что то упускаем. Дюже любопытно.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
vagrand
killer8080
twin
Да, кончено.
Есть распределенный сервис доставки контента.
По всему миру распределенный.
Множество инстансев одного сервиса, который называется image content delivery
И когда приходит новый файл, мы имеем выбор:
1: раскидать его по 1005000 файловых систем, где крутятся инстансы нашего delivery сервиса и отхватить кучу проблем с синхронизацией, если мы имеем событие source update, например
2: пишем небольшой файл в базу as BLOB in to cluster DB, из которого прочитает каждый инстанс сервиса и не делать голову ни Саре, ни Мойше.
_____________
[продано копирайтерам]
killer8080
twin
Да, кончено.
Есть распределенный сервис доставки контента.
По всему миру распределенный.
Множество инстансев одного сервиса, который называется image content delivery
И когда приходит новый файл, мы имеем выбор:
1: раскидать его по 1005000 файловых систем, где крутятся инстансы нашего delivery сервиса и отхватить кучу проблем с синхронизацией, если мы имеем событие source update, например
2: пишем небольшой файл в базу as BLOB in to cluster DB, из которого прочитает каждый инстанс сервиса и не делать голову ни Саре, ни Мойше.
_____________
[продано копирайтерам]
| Цитата (AllesKlar @ 22.12.2017 - 01:20) |
| пишем небольшой файл в базу as BLOB in to cluster DB, из которого прочитает каждый инстанс сервиса и не делать голову ни Саре, ни Мойше. |
Чем не угодил отдельный сервер для файлов? Не ты ли недавно за микросервисы ратовал? 
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (vagrand @ 21.12.2017 - 21:05) | ||
AllesKlar
Реальный пример подскажите, где обосновано хранить файлы в БД (реляционная или нет не имеет значения), а не в файловой системе? Ну и пример NoSQL базы, заточенной под хранение файлов настолько, что производительность выше хранения их в файловой системе, а то я вдруг действительно не знаю каких-то хороших инструментов. |
Одно время была модна mongodb + gridfs. Люди юзали. Выкладывали статьи и исследования с посылом о том, что в некоторых случаях оно имеет смысл. Я даже неким боком сталкивался с проектом, где это было.
Сейчас как-то подутихло. Возможно оно не имеет смысла, а возможно просто мода изменилась. А против моды, как вы понимаете, не попрешь же.
Вот по теме статья нагуглилась https://habrahabr.ru/company/oleg-bunin/blog/313364/
Там чуваки тоже решили разработать собственное файловое хранилище на базе nosql субд.
_____________
Чатик в телеге
AllesKlar
| Цитата |
| 1: раскидать его по 1005000 файловых систем, где крутятся инстансы нашего delivery сервиса и отхватить кучу проблем с синхронизацией, если мы имеем событие source update, например |
О каких проблемах идет речь? Я далек от утверждения, что знаю на 100% как устроены крупные CDN, но думаю что они используют что-то вроде Rsync Daemon. Как минимум именно его бы я использовал, случись мне строить собственную CDN.
| Цитата |
| 2: пишем небольшой файл в базу as BLOB in to cluster DB, из которого прочитает каждый инстанс сервиса и не делать голову ни Саре, ни Мойше. |
Несколько моментов по этому пункту:
1. Я просил указать конкретное название хотя бы одной БД заточенной под хранение и отдачу файлов.
2. Как можно заранее знать, если строишь CDN, какой размер файлов в ней будет храниться? Или предлагается ограничивать пользователя в размере заливаемого файла? Ну тогда это какая-то сильно ущербная CDN выходит.
3. Rsync Daemon решает все возможные проблемы с синхронизацией файлов между нодами CDN.
_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
нужно почитать про репликацию и шардинг и как это работает.
nosql базы - это базы исключительно журналирования. когда у вас идет огромное кол-во событий - и нагружать реляционную бд этим чревато падением произв-ти - тогда используют nosql. во всех остальных случаях использовать nosql-хранилища не имеет смысла.
странно наблюдать было раньше когда все описывали как хранить реляционную модель данных в не реляционной бд. это глупо.
при реально большом кол-ве файлов лучше всего хранить их на разных серверах непосредственно в фс системе и отдавать легковесным сервером.
nosql базы - это базы исключительно журналирования. когда у вас идет огромное кол-во событий - и нагружать реляционную бд этим чревато падением произв-ти - тогда используют nosql. во всех остальных случаях использовать nosql-хранилища не имеет смысла.
странно наблюдать было раньше когда все описывали как хранить реляционную модель данных в не реляционной бд. это глупо.
при реально большом кол-ве файлов лучше всего хранить их на разных серверах непосредственно в фс системе и отдавать легковесным сервером.
| Цитата (twin @ 22.12.2017 - 03:50) | ||
Чем не угодил отдельный сервер для файлов? Не ты ли недавно за микросервисы ратовал? |
Это уже не CDN. CDN - это Content Delivery Network, а если один сервер, то это уже никакая не
Network
И будут ли файлы на одном сервере или каждый delivery сервер будет иметь собственное файловое хранилище - никак не связано микросервисы ли это или монолит, раскиданный по серверам.
| Цитата (vagrand @ 22.12.2017 - 09:36) |
| Несколько моментов по этому пункту: 1. Я просил указать конкретное название хотя бы одной БД заточенной под хранение и отдачу файлов. 2. Как можно заранее знать, если строишь CDN, какой размер файлов в ней будет храниться? Или предлагается ограничивать пользователя в размере заливаемого файла? Ну тогда это какая-то сильно ущербная CDN выходит. 3. Rsync Daemon решает все возможные проблемы с синхронизацией файлов между нодами CDN. |
Естественно, ко всему нужно подходить с умом.
Никто не собирается в базу пихать пользовательский файл.
Но есть, например preview, которые генерируются нашей системой, и эти превьюшки все по 100-200 kb и они отличные кандитаты для документо-ориентированной базы данных.
Нет конкретно под файлы заточенной базы, есть под документы. Далее включаем голову и решаем, что и где хранить будет более рационально.
По п.п. 3 - rsync - это последний шаг при синхронизации.
Есть еще логические моменты, предшествующие вызову rsync.
Приходит запрос на файл, Request-Server должен знать, где какая нода уже имеет данный файл, и какая нода имеет действительно актуальную версию файла, чтобы не получилось 404 или еще хуже - отдать старую версию файла, потому что rsync еще не успел обновить файл на данной ноде.
Это всё легко на пальцах и на диване
на практике же у нас бегает несколько демонов, которые сравнивают хеш-суммы файлов на всех нодах, и шлют матерные алерты, если вдруг произошла рассинхронизацая.А рассинхронизации происходят. Не часто, но бывает. А так как мы берем деньги за свою CDN, то рассинхронизация - это прям вообще не хорошо, ну очень, я бы сказал плохо и дорого в настоящих деньгах
А почему рассинхронизации? А ХЗ, потому что кто-то выпустил новую фичу и где-то в модуле черт знает каком, никто не знает в каком, что-то пошло криво. А времени разбираться нет, рукожопа накажем завтра, а сегодня нужно доставлять контент и доставлять его правильно
_____________
[продано копирайтерам]
Здесь расположена полная версия этой страницы.