Спасибо. Выглядет рабочим. А вот отфильтровать сами коментарии могу? Чтобы поле comments имело только записи до 2001.01.03

Да, можно и так.

Можно фильтроват и пересобирать другой json

давайте я еще раз спрошу: что будет, когда туда набьется несколько тысяч комментариев по килобайту каждый?

Конечно будет плохо. Для этого такое использовать не стоит

@@@ Мы работаем в ногу со временем и храним все в JSON @@@ Используем автоинкремент отдельным полем, а почему вы спрашиваете?

Ты так говришь, как будто в монге нет списка с документами и у этого списка (двумерной таблички Карл) нет айдишника и индексов.

Но если это write only данные, например логи, то такой проблемы не стоит

давайте я еще раз спрошу: что будет, когда туда набьется несколько тысяч комментариев по килобайту каждый?

Ну я участвовал в разрботке базы где сотни лямов записей с достаточно сложным json.

У меня есть такие данные которые просто приходят и их надо считать. Они никогда не меняются. Согласен что с postgress можно это тоже сделать

Конешн оптимизировать-секционировать приходится, но зато работает быстро.

Ты так говришь, как будто в монге нет списка с документами и у этого списка (двумерной таблички Карл) нет айдишника и индексов.

там айдишник часть документа

и строить индекс по айди или по другому полю - функциональной разницы нет (кроме шардирования)

Ну я участвовал в разрботке базы где сотни лямов записей с достаточно сложным json.

ага, а на вопрос ответить?

там айдишник часть документа

Ахаха

ага, а на вопрос ответить?

Работать будет.

Или это не ответ на твой ответ? :)

Давайте так. Если данные нужно только собирать и считать - до можно и в JSON и это удобнее и проще. Если же данные нужно модифицировать и проверять структуру - то JSON не подходит - нужна реляционная структура. Согласны?

Работать будет.

то есть тебе ок хранить записи по несколько мегабайт и вытаскивать все комментарии для условной рсс?

то есть тебе ок хранить записи по несколько мегабайт и вытаскивать все комментарии для условной рсс?

Впорос не понятен.

Ты не хочешь вытаскиватьт все комментсы?

Или хочешь чтобы они отдельно хранились?

Никто тебя не заставляет всё сразу выдавать, выдавай ток то что нужно, не гоняй по сети лищние мегабайты.

Давайте так. Если данные нужно только собирать и считать - до можно и в JSON и это удобнее и проще. Если же данные нужно модифицировать и проверять структуру - то JSON не подходит - нужна реляционная структура. Согласны?

Целостность постгресина проверяет, не даст вставить всякую дичь.

Впорос не понятен.

шикардос

И можно модифицировать, почему ж нельзя.

Никто тебя не заставляет всё сразу выдавать, выдавай ток то что нужно, не гоняй по сети лищние мегабайты.

то есть по-твоему бд умеет вытаскивать поле текста, не подтягивая при этом остальные поля?

то есть по-твоему бд умеет вытаскивать поле текста, не подтягивая при этом остальные поля?

А по твоему она не умеет? :)

ага

ну, из джсона - если это не было понятно из контекста

ага

Ну ок, тебе виднее.

Ну я участвовал в разрботке базы где сотни лямов записей с достаточно сложным json.

Это типа аргумент? А я был в хедофисе гугл и эпл. Ты проиграл.

ну, из джсона - если это не было понятно из контекста

А чем джсон так уж отличается от других видов данных?

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

Это типа аргумент? А я был в хедофисе гугл и эпл. Ты проиграл.

Это ваще-то был ответ на вопрос.

А чем джсон так уж отличается от других видов данных?

тем, что он не бинарный

Это ваще-то был ответ на вопрос.

Не. Это не ответ

тем, что он не бинарный

Блин, ну почитай книжку, в Постгресине есть json и jsonb - последний как раз бинарный.

jsonb - распарсен.

Ребят, я понимаю что вам кажется что никто кроме монги не додумался ни до чего, но в реальности практическки всё уже давно в постгресине есть.

бинарный небинарный формат

это что-то вроде синхронной репликации?

https://postgrespro.ru/docs/postgrespro/10/datatype-json

Ребят, я понимаю что вам кажется что никто кроме монги не додумался ни до чего, но в реальности практическки всё уже давно в постгресине есть.

Я как раз переношу хранилку. Попробую завтра тоже самое запилить на Mongo и Postgres. Сравним

бгггг сам иди читай > Данные JSON, как и данные любых других типов, хранящиеся в таблицах, находятся под контролем механизма параллельного доступа. Хотя хранить большие документы вполне возможно, не забывайте, что при любом изменении устанавливается блокировка всей строки (на уровне строки). Поэтому для оптимизации блокировок транзакций, изменяющих данные, стоит ограничить размер документов JSON разумными пределами. В идеале каждый документ JSON должен собой представлять атомарный информационный блок, который, согласно бизнес-логике, нельзя разделить на меньшие, индивидуально изменяемые блоки.

бгггг сам иди читай > Данные JSON, как и данные любых других типов, хранящиеся в таблицах, находятся под контролем механизма параллельного доступа. Хотя хранить большие документы вполне возможно, не забывайте, что при любом изменении устанавливается блокировка всей строки (на уровне строки). Поэтому для оптимизации блокировок транзакций, изменяющих данные, стоит ограничить размер документов JSON разумными пределами. В идеале каждый документ JSON должен собой представлять атомарный информационный блок, который, согласно бизнес-логике, нельзя разделить на меньшие, индивидуально изменяемые блоки.

Ага, а что тебя смущает? :)

стоит ограничить размер документов JSON разумными пределами.

Ты хочешь хранить весь форум в одной строчке? :)

это ты предлагаешь все комментарии к посту сохранять

а я тебя все пытаюсть наставить на путь истинный

это ты предлагаешь все комментарии к посту сохранять

Ты не читаешь переписку, Дмитрий хотел такую схему в качестве примера Карл, а я просто пример кинул.

бгггг сам иди читай > Данные JSON, как и данные любых других типов, хранящиеся в таблицах, находятся под контролем механизма параллельного доступа. Хотя хранить большие документы вполне возможно, не забывайте, что при любом изменении устанавливается блокировка всей строки (на уровне строки). Поэтому для оптимизации блокировок транзакций, изменяющих данные, стоит ограничить размер документов JSON разумными пределами. В идеале каждый документ JSON должен собой представлять атомарный информационный блок, который, согласно бизнес-логике, нельзя разделить на меньшие, индивидуально изменяемые блоки.

Это не проблема. Обычно JSON хранилище нужно для таких задач. Есть данные, они постоянно приходят. Но что с ними делать еще не знаем. Когда узнаем - прикрутим индекс. Поэтому такие данные обычно неизменяемые. Если же хранить текущий баланс клиента в JSON - то да, это плохое решение

Тобишь тот запрос - сферический запрос в вакууме.

Ребят, я понимаю что вам кажется что никто кроме монги не додумался ни до чего, но в реальности практическки всё уже давно в постгресине есть.

Гыыы. Нам кажется что json нахер не нужен. Ни в монге ни в постгрине.

то есть тебе ок хранить записи по несколько мегабайт и вытаскивать все комментарии для условной рсс?

Ты не читаешь переписку, Дмитрий хотел такую схему в качестве примера Карл, а я просто пример кинул.

а ты судя по всему не читаешь, на что ты отвечаешь

то есть тебе ок хранить записи по несколько мегабайт и вытаскивать все комментарии для условной рсс?

Вопрос ко мне? К Дмитрию? Я должен ещё раз объяснять что тот пример был - сферическим? :)

Вопрос ко мне? К Дмитрию? Я должен ещё раз объяснять что тот пример был - сферическим? :)

тебе еще раз форварднуть то место, где ты сказал, что записи по несколько мегабайт - это ок?

Никто тебя не заставляет всё сразу выдавать, выдавай ток то что нужно, не гоняй по сети лищние мегабайты.

тебе еще раз форварднуть то место, где ты сказал, что записи по несколько мегабайт - это ок?

Давай форвардни. :)

то есть тебе ок хранить записи по несколько мегабайт и вытаскивать все комментарии для условной рсс?

Ок. Тогда более приближенная задача. С датчиков приходит 10 разных событий. У каждого типа свой набор полей. События нужно как и вместе агрегировать, так и по специализированным полям. Есть 3 варианта: 1) Одну таблицу и куча пустых полей 2) Одну таблицу с общими данными и 10 таблиц с специализированными данными 3) Одну таблицу с JSON и индексам по них. Какой вариант тебе ближе?

Да, такое может работать. Но выглядит странно. А покажи пример. К примеру мне нужно из постов блога где каждая запись блога - отдельный JSON документ вытащить все коментарии и слить их в один ответ. Как это будет выглядеть на postgres?

Это был пример на мой вопрос

Я бы начал с того, что посмотрел что вообще в time series сейчас есть, вместо того, чтобы прикручивать базу с MVCC к неизменяемым данным

Я бы начал с того, что посмотрел что вообще в time series сейчас есть, вместо того, чтобы прикручивать базу с MVCC к неизменяемым данным

Например Prometheus. У нас на нем мониторинг построен

Ок. Тогда более приближенная задача. С датчиков приходит 10 разных событий. У каждого типа свой набор полей. События нужно как и вместе агрегировать, так и по специализированным полям. Есть 3 варианта: 1) Одну таблицу и куча пустых полей 2) Одну таблицу с общими данными и 10 таблиц с специализированными данными 3) Одну таблицу с JSON и индексам по них. Какой вариант тебе ближе?

Мне ближе 2

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

Ну тут разные данные. Данные клиентов терять нельзя, поэтому что-то меганадежное нужно. А свой мониторинг за день можно и потерять если что-то большое сломается

ERROR: S client not available

Ок. Тогда более приближенная задача. С датчиков приходит 10 разных событий. У каждого типа свой набор полей. События нужно как и вместе агрегировать, так и по специализированным полям. Есть 3 варианта: 1) Одну таблицу и куча пустых полей 2) Одну таблицу с общими данными и 10 таблиц с специализированными данными 3) Одну таблицу с JSON и индексам по них. Какой вариант тебе ближе?

Мы те данные которые хорошо структурированы и как правило повторяются в каждой строке - сделали простыми колонками, а всё что изредка появляется и непонятно что - залили в json колонку.

в общем тащить типовое хранилище под append-only нагрузку это прям скажем так себе идея

Ок. Тогда более приближенная задача. С датчиков приходит 10 разных событий. У каждого типа свой набор полей. События нужно как и вместе агрегировать, так и по специализированным полям. Есть 3 варианта: 1) Одну таблицу и куча пустых полей 2) Одну таблицу с общими данными и 10 таблиц с специализированными данными 3) Одну таблицу с JSON и индексам по них. Какой вариант тебе ближе?

Поржал. У меня задаче данные приходят блоками по 48 тысяч штук. И каждый блок агрегируется с собой и другими. Но причем тут json? Агрегация это функция приложения а не базы

Мы те данные которые хорошо структурированы и как правило повторяются в каждой строке - сделали простыми колонками, а всё что изредка появляется и непонятно что - залили в json колонку.

Вот кстати хороший пример. Если структура не меняется. А как postgres c изменениями формата данных справляется? Например было у меня поле INT(10), а потом понадобилось его расширить под INT(20) так как в страну вышли со странными суммами. MySQL от этого с ума сходит на несколько часов.

Поржал. У меня задаче данные приходят блоками по 48 тысяч штук. И каждый блок агрегируется с собой и другими. Но причем тут json? Агрегация это функция приложения а не базы

База агрегирует внутри себя. И выдает результат. А выдавать на java процесс 1млн строк чтобы их сложить дорого

Вот кстати хороший пример. Если структура не меняется. А как postgres c изменениями формата данных справляется? Например было у меня поле INT(10), а потом понадобилось его расширить под INT(20) так как в страну вышли со странными суммами. MySQL от этого с ума сходит на несколько часов.

Не припомню чтобы сильно тормозили такие преобразования.

База агрегирует внутри себя. И выдает результат. А выдавать на java процесс 1млн строк чтобы их сложить дорого

Нет таких процессов.

Поржал. У меня задаче данные приходят блоками по 48 тысяч штук. И каждый блок агрегируется с собой и другими. Но причем тут json? Агрегация это функция приложения а не базы

Я ничего не понял, но ок, ты меня уел.

Мой процесс поместился в чуть больше 1к строк на жабе

База агрегирует внутри себя. И выдает результат. А выдавать на java процесс 1млн строк чтобы их сложить дорого

эм, дорого что?

Нет таких процессов.

Да ладно. Клиент отчет за год попросит отчет с разрезом по месяцам и пошла база складывать миллион записей

Да ладно. Клиент отчет за год попросит отчет с разрезом по месяцам и пошла база складывать миллион записей

Значит проектировщик дебил

эм, дорого что?

Сеть, CPU процесса, память процесса. Да и задержка большая - отдать млн строк

Значит проектировщик дебил

Если клиент платит то почему бы и нет

Сеть, CPU процесса, память процесса. Да и задержка большая - отдать млн строк

А json причем

Если клиент платит то почему бы и нет

А причем тут платит)?

А json причем

Это был ответ на эту цитату » Агрегация это функция приложения а не базы

Это был ответ на эту цитату » Агрегация это функция приложения а не базы

И таки да. В чем проблема то?

Ладно, Объясни что ты имел ввиду под фразой "Агрегация это функция приложения а не базы"? Почему это должен делать серверный процесс, а не база?

Сеть, CPU процесса, память процесса. Да и задержка большая - отдать млн строк

мне бы ваши проблемы на миллионе строк

Ладно, Объясни что ты имел ввиду под фразой "Агрегация это функция приложения а не базы"? Почему это должен делать серверный процесс, а не база?

Твои данные которые приходят нужно раскладывать согласно твоей архитектуры что бы не получалось ситуаций когда нужно миллионы строк складывать или отдаэвать

Имеешь ввиду предварительно агрегировать на более большие сегменты?

Имеешь ввиду предварительно агрегировать на более большие сегменты?

Как вариант

Вариантов вагон

Твои данные которые приходят нужно раскладывать согласно твоей архитектуры что бы не получалось ситуаций когда нужно миллионы строк складывать или отдаэвать

Попахивает изобретением собственной СУБД на Java. Нет, я не осуждаю! Понять и простить! :)

Попахивает изобретением собственной СУБД на Java. Нет, я не осуждаю! Понять и простить! :)

Все еще не ясно зачем json

Все еще не ясно зачем json

Не нужен json. Согласен. Давай писать на java свою СУБД.

Попахивает изобретением собственной СУБД на Java. Нет, я не осуждаю! Понять и простить! :)

кассандра-то чем не устроила

Не нужен json. Согласен. Давай писать на java свою СУБД.

Зачем? Тебе имеющизся мало? Кассандра шикарна например

Кассандра? Отлично!