ВН
А что мешало-то файлики разложить по сервачкам?
очумелые ручки %))
Но так-то весело вышло, конечно
Дофига работы по переездам и несколько докладов
С Хетцнера, кстати, вроде слезли в servers.com, но тут я уже плохо помню
Size: a a a
2020 November 18
AV
Обоснуй
(Сперва обоснуй, а потом мы обсудим именно постгресовскую реализацию, бггг)
(Сперва обоснуй, а потом мы обсудим именно постгресовскую реализацию, бггг)
Если мы говорим про задачу раздачу большого кол-ва файлов, про что речь как раз и шла то
1. Масштабировать СУБД сложнее чем файлуху
2. При работе с blobами СУБД жрет куда больше ресурсов
3. Скорость работы ниже
4. Бекапы сложнее
1. Масштабировать СУБД сложнее чем файлуху
2. При работе с blobами СУБД жрет куда больше ресурсов
3. Скорость работы ниже
4. Бекапы сложнее
AV
В общем если речь идет про решения, где это например какая то система документооборота, то многие используют блобы
S
Горизонтально она не масштабируется, но можно много базок маленьких
нельзя много маленьких баз, ибо USE как в MySQL нет, можно "много маленьких таблиц" с суффиком или с разными именами schema
и vacuum надо очень аггрессивно для такого паттерна настраивать
потому что блобы это extended и новый блоб идет как новый page
и vacuum надо очень аггрессивно для такого паттерна настраивать
потому что блобы это extended и новый блоб идет как новый page
ВН
нельзя много маленьких баз, ибо USE как в MySQL нет, можно "много маленьких таблиц" с суффиком или с разными именами schema
и vacuum надо очень аггрессивно для такого паттерна настраивать
потому что блобы это extended и новый блоб идет как новый page
и vacuum надо очень аггрессивно для такого паттерна настраивать
потому что блобы это extended и новый блоб идет как новый page
а ещё не дай бог ты будешь их обновлять/удалять, т.к. вакуум
ВН
хотя если только добавляешь, то это не страшно, да
AS
Alexey Vasilyev
Если мы говорим про задачу раздачу большого кол-ва файлов, про что речь как раз и шла то
1. Масштабировать СУБД сложнее чем файлуху
2. При работе с blobами СУБД жрет куда больше ресурсов
3. Скорость работы ниже
4. Бекапы сложнее
1. Масштабировать СУБД сложнее чем файлуху
2. При работе с blobами СУБД жрет куда больше ресурсов
3. Скорость работы ниже
4. Бекапы сложнее
Все четыре утверждения спорны
1) Ну - залей в один каталог на FS 150 миллионов файлов, дальше мы посмотрим, что будет
2) У постгреса вообще double buffering, сложно себе представить, чтобы он ресурсы не жрал, но что так page cache, что так page cache - просто под постгресом его меньше останется
3) За счет чего она ниже-то?
4) Бэкапы это вообще не очень просто
1) Ну - залей в один каталог на FS 150 миллионов файлов, дальше мы посмотрим, что будет
2) У постгреса вообще double buffering, сложно себе представить, чтобы он ресурсы не жрал, но что так page cache, что так page cache - просто под постгресом его меньше останется
3) За счет чего она ниже-то?
4) Бэкапы это вообще не очень просто
AS
нельзя много маленьких баз, ибо USE как в MySQL нет, можно "много маленьких таблиц" с суффиком или с разными именами schema
и vacuum надо очень аггрессивно для такого паттерна настраивать
потому что блобы это extended и новый блоб идет как новый page
и vacuum надо очень аггрессивно для такого паттерна настраивать
потому что блобы это extended и новый блоб идет как новый page
А вот вакуум, как раз, у нас ничего не вакуумил, потому что мы ничего не удаляли
AS
Что в голову приходит практически сразу
AV
Все четыре утверждения спорны
1) Ну - залей в один каталог на FS 150 миллионов файлов, дальше мы посмотрим, что будет
2) У постгреса вообще double buffering, сложно себе представить, чтобы он ресурсы не жрал, но что так page cache, что так page cache - просто под постгресом его меньше останется
3) За счет чего она ниже-то?
4) Бэкапы это вообще не очень просто
1) Ну - залей в один каталог на FS 150 миллионов файлов, дальше мы посмотрим, что будет
2) У постгреса вообще double buffering, сложно себе представить, чтобы он ресурсы не жрал, но что так page cache, что так page cache - просто под постгресом его меньше останется
3) За счет чего она ниже-то?
4) Бэкапы это вообще не очень просто
1, Ну это кривая реализация, тут можно так же сказать, что сделать таблицу без индексов в 150М записей
2. При использовании таких отдач через СУБД, мы нагружаем воркеров субд, которые жрут куда больше чем например тот же Nginx
3. Потому что а) может хранится не оптимально б) дополнительные слои абстракции по сравнению с другими решениями
4. Это да, но тут еще размер СУБД растет со страшной силой
2. При использовании таких отдач через СУБД, мы нагружаем воркеров субд, которые жрут куда больше чем например тот же Nginx
3. Потому что а) может хранится не оптимально б) дополнительные слои абстракции по сравнению с другими решениями
4. Это да, но тут еще размер СУБД растет со страшной силой
G
Все четыре утверждения спорны
1) Ну - залей в один каталог на FS 150 миллионов файлов, дальше мы посмотрим, что будет
2) У постгреса вообще double buffering, сложно себе представить, чтобы он ресурсы не жрал, но что так page cache, что так page cache - просто под постгресом его меньше останется
3) За счет чего она ниже-то?
4) Бэкапы это вообще не очень просто
1) Ну - залей в один каталог на FS 150 миллионов файлов, дальше мы посмотрим, что будет
2) У постгреса вообще double buffering, сложно себе представить, чтобы он ресурсы не жрал, но что так page cache, что так page cache - просто под постгресом его меньше останется
3) За счет чего она ниже-то?
4) Бэкапы это вообще не очень просто
> 1) Ну - залей в один каталог на FS 150 миллионов файлов, дальше мы посмотрим, что будет
вопрос - зачем?))
вопрос - зачем?))
S
А вот вакуум, как раз, у нас ничего не вакуумил, потому что мы ничего не удаляли
UPDATE был? или только INSERT + SELECT?
i
> 1) Ну - залей в один каталог на FS 150 миллионов файлов, дальше мы посмотрим, что будет
вопрос - зачем?))
вопрос - зачем?))
Интернет-магазин с лёгкостью пробьёт этот порог тамбнейлами и фотками товара с разных планов
AS
Alexey Vasilyev
1, Ну это кривая реализация, тут можно так же сказать, что сделать таблицу без индексов в 150М записей
2. При использовании таких отдач через СУБД, мы нагружаем воркеров субд, которые жрут куда больше чем например тот же Nginx
3. Потому что а) может хранится не оптимально б) дополнительные слои абстракции по сравнению с другими решениями
4. Это да, но тут еще размер СУБД растет со страшной силой
2. При использовании таких отдач через СУБД, мы нагружаем воркеров субд, которые жрут куда больше чем например тот же Nginx
3. Потому что а) может хранится не оптимально б) дополнительные слои абстракции по сравнению с другими решениями
4. Это да, но тут еще размер СУБД растет со страшной силой
3) По сравнению со скоростью вращающегося диска пофиг вообще
AS
> 1) Ну - залей в один каталог на FS 150 миллионов файлов, дальше мы посмотрим, что будет
вопрос - зачем?))
вопрос - зачем?))
Это надо спросить у того, кто так делал
AS
UPDATE был? или только INSERT + SELECT?
Только на таблицу со связями между объектами (а она мелкая)
На таблицы с блобами - никаких апдейтов
На таблицы с блобами - никаких апдейтов
G
Интернет-магазин с лёгкостью пробьёт этот порог тамбнейлами и фотками товара с разных планов
ну так разложи по директориям, антипаттерн же
AV
3) По сравнению со скоростью вращающегося диска пофиг вообще
ну да, будет еще в два раза тормознее, делов то
AS
Alexey Vasilyev
ну да, будет еще в два раза тормознее, делов то
С фига бы?