Это сейчас о чем?

Это юзкейс такой

Вообще то у nosql определение "нет четкой структуры", а не когда много данных

Nosql это все, что не классический sql

И про отказоустойчивость не забудьте

Есть тогда вопрос по архитектуре... Есть некоторая система, в которую поступают документы. Нужно хранить тело документа (xml) и его метаинформацию. Предложите как это сделать SQL средствами. Документов порядка 150 млн. Объемом порядка 3 ТБ

1С. Все уже сделали до вас.

И про отказоустойчивость не забудьте

С этим у касандры лучше чем у постгри

1С. Все уже сделали до вас.

Очевидный троль )

Но постгря она для другого

С этим у касандры лучше чем у постгри

Вот поэтому я и говорю - посгря для метаинформации - касандра или еще множество всего - для документов

Очевидный троль )

Милейший, когда дорастете хотя бы до терабайта декомпозированных данных - тогда и будете обзываться.

Когда нужны транзакции, хранить информацию служебную о пользователях и так далее

Очень сложную аналитику по маленькому датасету

Милейший, когда дорастете хотя бы до терабайта декомпозированных данных - тогда и будете обзываться.

Мальчик мой, я подрос - мне уже можно

Есть тогда вопрос по архитектуре... Есть некоторая система, в которую поступают документы. Нужно хранить тело документа (xml) и его метаинформацию. Предложите как это сделать SQL средствами. Документов порядка 150 млн. Объемом порядка 3 ТБ

В данном случае nosql очевидно, ввиду документов

Мальчик мой, я подрос - мне уже можно

JSON в nosql базе - это несколько не тот случай.

JSON в nosql базе - это несколько не тот случай.

Нет - у меня другой случай. )

Nosql это все, что не классический sql

Хотите сказать, вертеть большие данные в классическом SQL не возможно?

В данном случае nosql очевидно, ввиду документов

Сейчас это реализовано - postgres - метаинформация - файлы на ФС - с дублированием.

Хотите сказать, вертеть большие данные в классическом SQL не возможно?

Возможно, но иногда есть более подходящие средства. Я привел пример выше.

Есть тогда вопрос по архитектуре... Есть некоторая система, в которую поступают документы. Нужно хранить тело документа (xml) и его метаинформацию. Предложите как это сделать SQL средствами. Документов порядка 150 млн. Объемом порядка 3 ТБ

Что за метаинформация? Какого рода?

Возможно, но иногда есть более подходящие средства. Я привел пример выше.

Ну а я могу привести пример колоночных БД

Идентификатор документа, контрольная сумма, дата запроса, источник документа

Классический SQL - не серебрянная пуля. Как впрочем и NoSQL.

Сейчас это реализовано - postgres - метаинформация - файлы на ФС - с дублированием.

сдается мне, что когда файлов станет поболее, то фс будет тормозить

JSON в nosql базе - это несколько не тот случай.

Немного о том с чем работаю 1 БД Oracle 11G RAC (Exadata) - 5 ТБ данных. 1 БД Oracle 11G RAC - 1,5 ТБ данных. 1 БД Oracle 11G RAC - 1 ТБ данных. Postgres штук 5-6 БД c ~100 - 600 ГБ И много баз поменьше (postgres, oracle, mysql, mssql).

есть куда расти)

сдается мне, что когда файлов станет поболее, то фс будет тормозить

Тормозят массовые операции. (xfs btree вызывает большое число syscall), и давно уже понятно что менять пора схему хранения. Но при таких объемах это небыстро и решения надо подбирать тщательно

есть куда расти)

Согласен. Развитие идет постоянно. NoSQL на самом деле открыл для себя сравнительно недавно - причем плотно мало с чем работал. Поддерживаю пару redis, memcached, couchbase. Немного монгу

В смысле - бородатый мальчик, не понимающий, чем left join отличается от inner?

Обидился даже на немного

Тормозят массовые операции. (xfs btree вызывает большое число syscall), и давно уже понятно что менять пора схему хранения. Но при таких объемах это небыстро и решения надо подбирать тщательно

чем обусловлен выбор в пользу xfs?

он вроде тормознутей ext4 и уменьшать его нельзя

он вроде тормознутей ext4 и уменьшать его нельзя

Inode в ней бесконечные

Когда-то был ext4, но inode кончились

Inode в ней бесконечные

это не беслпатно

а inode можно зарание задать

по больше

Рано или поздно и побольше кончится. В целом в тот момент стало понятно - нужно что-то другое

Не файлы на фс

Тормозят массовые операции. (xfs btree вызывает большое число syscall), и давно уже понятно что менять пора схему хранения. Но при таких объемах это небыстро и решения надо подбирать тщательно

Т.е. на postgres ext4 лучше xfs? Или xfs нужно уметь "готовить"?

Т.е. на postgres ext4 лучше xfs? Или xfs нужно уметь "готовить"?

для postgres ext4 лучше

Т.е. на postgres ext4 лучше xfs? Или xfs нужно уметь "готовить"?

Речь о работе с фс на которой много миллионов файлов

Рано или поздно и побольше кончится. В целом в тот момент стало понятно - нужно что-то другое

ну с postgres таких проблемм мало

Речь о работе с фс на которой много миллионов файлов

А что postgres может наплодить столько файлов?

для postgres ext4 лучше

А можно узнать чем лучше?

мы выбрали ext4, пока все норм (хотя в e2fsprogs часто косяки встречаются)

А можно узнать чем лучше?

Поддерживаю вопрос. Особенно в части асинхронного io

Тоже интересно

https://blog.pgaddict.com/posts/postgresql-performance-on-ext4-and-xfs

сколько не встречал статей в Интернете, кто то одно хвалит и графики даже приводит, кто то другое.

https://blog.pgaddict.com/posts/postgresql-performance-on-ext4-and-xfs

да я это читал

сколько не встречал статей в Интернете, кто то одно хвалит и графики даже приводит, кто то другое.

есть такое, каждый хвалит свое болото )))

Думаю разница будет не очень велика )

Возможно я ошибаюсь. Но асинхронные операции и параллельную запись поддерживает только xfs. Но пруфы в голове не всплывают

Вообще есть мнение, что key-value со всяческими прибамбасами придумали потому, что хипстеры в вузах не учились и нормализованную декомпозицию данных не умеют.

ахахаха

Это до тех пор, пока вам не нужно селектить эти json по неключевому значению. Когда становится нужно - вас увольняют и нанимают SQL-щиков :)

ахахаха

ох жирно

в общем, когда нужен сильно нестандартный поиск, sql тоже сосет, и выкручиваются эластиком/solr/sphinx, но никак не sql

Но никак не монга, в общем-то, тоже.

rdbms покрывают 99% задач, для остального есть es.

а для выборок по различным ключам делают вторичные коллекции с иным primary key - это раздувает датасет и не везде применимо, но ратовать за sql, потому что он умеет во вторичные индексы - это хаха

ну, можно хранить данные в чистом виде в файлах и получить покрытие 95% задач

Возможно я ошибаюсь. Но асинхронные операции и параллельную запись поддерживает только xfs. Но пруфы в голове не всплывают

Подскажите, пожалуйста, что означает "асинхронные операции и параллельная запись"?

ну, можно хранить данные в чистом виде в файлах и получить покрытие 95% задач

ACID?

пиши/читай под локом

задача-то покрыта

А как в postgres реализован large objects?

Хуево

Хуево

А можно получить более развёрнутый ответ?

А можно получить более развёрнутый ответ?

https://www.postgresql.org/docs/9.6/static/storage-toast.html ?

https://www.postgresql.org/docs/9.6/static/storage-toast.html ?

кмк, https://www.postgresql.org/docs/current/static/largeobjects.html

PostgreSQL also supports a storage system called "TOAST", which automatically stores values larger than a single database page into a secondary storage area per table

кмк, https://www.postgresql.org/docs/current/static/largeobjects.html

мож быть, не знаю что он имел в виду )

Не факт ,что TOAST используется

Я тоже)

насчёт LO могу сказать, что тот ещё гемор

Почему?)

если использовать, то сразу брать для них extension

https://www.postgresql.org/docs/current/static/lo.html

мож быть, не знаю что он имел в виду )

Ну наверно всё-таки то, как это внутри устроено. Там просто файловый интерфейс

Почему?)

Потому что нет удаления, надо всё сделать руками, чтобы работало

int lo_unlink(PGconn *conn, Oid lobjId);

задача-то какая? файлы лучше в постгресе не хранить )

int lo_unlink(PGconn *conn, Oid lobjId);

ага, не только лишь все приложения это делают

Ну вы подскажите что-нибудь ещё. А то просто какие-то утверждения. Задачи нет. Я сейчас всегда в постгресе храню, думал, что это нормально.

extension стоит?

Там streaming интерфейс, поэтому можно не выгружать весь файл, а отдавать по chank-ам...

lo

Нет

Подскажите, пожалуйста, что означает "асинхронные операции и параллельная запись"?

А ещё мне интересно узнать, что здесь имелось ввиду)

Ну вы подскажите что-нибудь ещё. А то просто какие-то утверждения. Задачи нет. Я сейчас всегда в постгресе храню, думал, что это нормально.

чисто теоретически: - прочитать файл прямо с диска: чтение Х байт с диска, пересылка Х байт по сети - прочитать файл из БД: чтение Y>=X байт с диска, пересылка Z>=X байт по сети/сокету к приложению, пересылка Х байт по сети, причем все это еще проходит через буфера в юзерлэнде, если нет возможности прогнать через zero copy

Там streaming интерфейс, поэтому можно не выгружать весь файл, а отдавать по chank-ам...

Конечно это не означает, что файл из ФС нельзя кусками отдавать

А почему пересылка Z байт?

потому что uuencode

я не знаю сетевого протокола постгре, но, насколько понимаю, возвращенный ответ будет как минимум чуть больше самих данных. скорее всего, там будет незначительная разница, но скзаать, что там тот же Х, я не могу.

в текстовом протоколе оно пойдёт или хексом, или строкой с эскейпингом https://www.postgresql.org/docs/9.6/static/datatype-binary.html

текстовый протокол == сетевой?

Тормозят массовые операции. (xfs btree вызывает большое число syscall), и давно уже понятно что менять пора схему хранения. Но при таких объемах это небыстро и решения надо подбирать тщательно

Эээ? Как внутренности фс влияют на число сисколлов?

текстовый протокол == сетевой?

у постгреса есть текстовый и бинарный output, https://www.postgresql.org/docs/9.6/static/protocol-flow.html

а inode можно зарание задать

Можно, но так же легко промахнутся с их числом. А операции с метаданными в xfs быстрее. Плюс, в xfs сейчас более-менее работает aio

текстовый протокол == сетевой?

мало кто имплементирует бинарный output, к сожалению. а кто имплементируют, те потом давятся кастомными типами :)