При этом вы должны понимать, что не надо весь текст вытаскивать из ячейки, чтобы его обновить, достаточно туда просто добавить текст, а ля update table set text = text + new_text.
1. найти нужную запись из миллиарда обновить ее и перестроить индекс?
2. найти нужную запись из сотен тысяч, обновить текст и сохранить его обратно не трогая индексы?
Какие миллиарды записей, скорее миллион? В разделе хранятся данные из чата за 10 дней ≈ 100 МБ.
а заголовок о чем говорит? Говорит о том что успешные пацаны научились без тормозов хранить 1кк записей. У меня сразу вопрос: а что будет если их будет 10кк или 100кк. Опять будут думать как хранить данные?
Сообщения удаляются не так часто чтобы перестроение индексов было критичным.
индексы перестраиваются при UPDATE, DELETE, INSERT.
Вы какую СУБД предлагаете использовать?
я не предлагаю какую-либо БД конкретно, я взываю к логике: хранить не отдельные реплики, а хранить диалоги в одном месте. Как уже приводил пример с диктофоном ниже.
Вот у вас есть на телефон диктофон. Вы записываете разговор 10-рых людей. Вы же не пишете слова или реплики каждого человека в отдельный файл. Вы записываете всех и сразу, в единую запись. Чем чат отличается от диалога на диктофон? Да по сути ничем. Вы собираетесь менять слова говорящих, их интонацию, последовательность разговора? Нет конечно. Так и с чатом. Все что было сказано — это единое целое и зачем это разбивать на отдельный записи каждой реплики, если там ничего не изменится? Ни автор, ни дата, ни последовательность? Так хранить это как единый диалог всех участников.
и какие ограничения? 1 гигабайт? Как у текстового поля? json тип и есть текстовое поле, только с валидацией.
записать пару мегабайт текста проще чем обновить таблицу с миллиардами записей из-за перестроения индексов. Да и я уже ниже написал, что чат размером в 2 мегабайта — это предел мечтаний.
кстати вот статья про постгрес и бенчмарки работы с JSON https://hashrocket.com/blog/posts/faster-json-generation-with-postgresql
да даже если пользователю через websocket или AJAX отгрузить 2 мегабайта данных, то на стороне JS можно также делать выборку из цикла. На крайний случай разбить на несколько массивов, например помесячно или недельно. Так работают Whatsapp и Skype. Они отдают кусками, при подгрузке.
два мегабайта — это 2 097 000 байт. Длина одного символа UTF8 составляет от 1 до 6 байт. Возьмем среднее значение 3. То есть в 2 097 000 уместится 699000 тысяч символов. Средняя длина слова в английском языке составляет около 5 символов, соответственно это около 139800 слов. Средняя длина предложения в чате — 6 слов. То есть 23 300 предложений или сообщений в одном чате. Где вы видели чаты с таким количеством сообщений?
И потом никто не предлагает весь чат передавать на сторону клиента. Подгружать только последние 30-40 допустим, а если человек хочет прошлые посмотреть, загружай нужный период через AJAX и отдавай пользователю кусками.
я предлагаю хранить текст чата в БД в виде JSON строки. Это логически правильно. Тем более базы умеет делать выборку по JSON, а некоторые не то чтобы обновлять отдельные поля, но и даже строить индексы по полям в JSON.
Если хранить каждое сообщение отдельно, как делают в статье, то если есть 10 чатов по 10 человек и каждый напишет в чат по одному сообщению, то это получится будет 100 записей. Если хранить диалог, то это так и останется 10 строк в базе, что на порядок меньше. А если количество пользователей и их сообщений будет увеличиваться арифметически, то количество строк будет увеличиваться геометрически. Поэтому и пришли к тупику как хранить миллиарды сообщений. Завтра им придется хранить 10 или 100 миллиардов сообщений и они опять придут к тупику как жить дальше.
Мне кажется чат надо хранить в JSON либо в другом сериализаторе. Или хотя бы XML.
1. Чат это текст, соответственно хранить как текст
2. Отправитель и получатель никогда не изменяются
3. Данные о дате сообщения никогда не изменяются.
так почему бы не хранить это статически?
В случае чата каждый с каждым — это не куча записей в базе по каждому сообщению, а только одна запись диалога… при чем даже не надо на стороне сервера что-то парсить, пусть делает JS и рисует на основе данных интерфейс.
и средствами самой базы легко, в случае JSON, делать как выборки, так и апдейты с инсертами.
ну я написал одному из крупнейших партнеров, на что получил вот такой вот ответ:
Добрый день!
Мы оказываем консультационные услуги только по использованию типовых решений для Казахстана и отраслевых решений компании «1С-Рейтинг».
Вопросы по использованию возможностей платформы «1С: Предприятие» при доработке/разработке конфигураций Вы можете задавать на специализированном форуме участников-партнеров https://partners.v8.1c.ru/.
В частности, по Вашему вопросу есть похожие сообщения https://partners.v8.1c.ru/forum/topic/1560477#m_1560477, https://partners.v8.1c.ru/forum/message/1561229#m_1561229, в которых данная ситуация признана ошибкой платформы.
Спасибо. Не дожидаясь ответа реализовал еще пару недель назад.
Вызов веб сервера осуществляется локально, то есть в одной подсети виртуальных машин на гипервизоре.
Сам веб сервер только лишь принимает данные и транслирует их в сокет и отвечает кодом 200. То есть по сути является прокси.
А сокеты уже сами куда надо отправляют и обрабатывают данные. Так что не вижу смысла формировать фоновые задания.
Единственное, в расширениях нельзя иметь константы, обработчики и чего-то еще… не помню… пришлось снимать с поддержки.
Каждый раз, когда я слышу, что в ЦОНе или в Казпочте или даже в Народном банке зависла база, я с огромным недоумением и с матерными словами в голове спрашиваю себя: «Ну как так то?»
Тот же самый Stack Exchange Network имеет 20 серверов и обслуживает в месяц столько уникальных пользователей, сколько населения в Казахстане.
Для примера только Krisha.kz вместе с Kolesa.kz работают на 650-ти серверах. Почти в 33 раза больше чем у Stack Exchange и при этом обслуживают в тысячи раз меньше пользователей.
У нас местные лидеры отрасли не могут создать инфраструктуру для самих себя, а вы тут про гос аппарат…
Вот для примера:
когда вы пассажир и смотрите в приложение, то вам показывается как движется автомобиль. На самом деле данные не реалтайм, а построены на фильтре Калмана. Слава богу что они додумались его использоваться. Но вместо того, чтобы открывать сокет и передавать в него данные, водительское приложение через HTTP запрос передает свои координаты, а сервер ему возвращает поллинг интервал когда сообщить в следующий раз.
В итоге получаем, что водитель уже на месте, а у пользователя по фильтру калмана водитель проехал дальше на пару километров вперед. А все потому что сервер ответил водителю передать свои координаты через 3 минуты, допустим. И это самый банальный пример.
очень и очень много ковырял приложения как водительское так и пользовательское… могу сказать, что код писали индусы… криво, косо, не эффективно и иногда вообще адски! Планирую об этом статью написать
А можно ли с помощью расширения конфигурации отлавливать допустим создание, изменение, отмену проводки, пометки на удаление и удаление какого-либо документа и инициировать http запрос на сторонний сервер с указанием данных, например uuid документа и тип операции?
Почему с помощью расширения? — Не хочется снимать с поддержки конфигурацию.
Задача информировать внешние интеграционные системы об изменениях в базе, нежели регулярно опрашивать.
Но предлагаю задуматься и ответить что быстрее:
1. найти нужную запись из миллиарда обновить ее и перестроить индекс?
2. найти нужную запись из сотен тысяч, обновить текст и сохранить его обратно не трогая индексы?
индексы перестраиваются при UPDATE, DELETE, INSERT.
я не предлагаю какую-либо БД конкретно, я взываю к логике: хранить не отдельные реплики, а хранить диалоги в одном месте. Как уже приводил пример с диктофоном ниже.
записать пару мегабайт текста проще чем обновить таблицу с миллиардами записей из-за перестроения индексов. Да и я уже ниже написал, что чат размером в 2 мегабайта — это предел мечтаний.
кстати вот статья про постгрес и бенчмарки работы с JSON https://hashrocket.com/blog/posts/faster-json-generation-with-postgresql
И потом никто не предлагает весь чат передавать на сторону клиента. Подгружать только последние 30-40 допустим, а если человек хочет прошлые посмотреть, загружай нужный период через AJAX и отдавай пользователю кусками.
Если хранить каждое сообщение отдельно, как делают в статье, то если есть 10 чатов по 10 человек и каждый напишет в чат по одному сообщению, то это получится будет 100 записей. Если хранить диалог, то это так и останется 10 строк в базе, что на порядок меньше. А если количество пользователей и их сообщений будет увеличиваться арифметически, то количество строк будет увеличиваться геометрически. Поэтому и пришли к тупику как хранить миллиарды сообщений. Завтра им придется хранить 10 или 100 миллиардов сообщений и они опять придут к тупику как жить дальше.
1. Чат это текст, соответственно хранить как текст
2. Отправитель и получатель никогда не изменяются
3. Данные о дате сообщения никогда не изменяются.
так почему бы не хранить это статически?
В случае чата каждый с каждым — это не куча записей в базе по каждому сообщению, а только одна запись диалога… при чем даже не надо на стороне сервера что-то парсить, пусть делает JS и рисует на основе данных интерфейс.
и средствами самой базы легко, в случае JSON, делать как выборки, так и апдейты с инсертами.
Черт побери, а тема то работает, народ повылазил…
а вот здесь вот поподробнее пожалуйста
Вызов веб сервера осуществляется локально, то есть в одной подсети виртуальных машин на гипервизоре.
Сам веб сервер только лишь принимает данные и транслирует их в сокет и отвечает кодом 200. То есть по сути является прокси.
А сокеты уже сами куда надо отправляют и обрабатывают данные. Так что не вижу смысла формировать фоновые задания.
Единственное, в расширениях нельзя иметь константы, обработчики и чего-то еще… не помню… пришлось снимать с поддержки.
Каждый раз, когда я слышу, что в ЦОНе или в Казпочте или даже в Народном банке зависла база, я с огромным недоумением и с матерными словами в голове спрашиваю себя: «Ну как так то?»
Тот же самый Stack Exchange Network имеет 20 серверов и обслуживает в месяц столько уникальных пользователей, сколько населения в Казахстане.
Для примера только Krisha.kz вместе с Kolesa.kz работают на 650-ти серверах. Почти в 33 раза больше чем у Stack Exchange и при этом обслуживают в тысячи раз меньше пользователей.
У нас местные лидеры отрасли не могут создать инфраструктуру для самих себя, а вы тут про гос аппарат…
Вот для примера:
когда вы пассажир и смотрите в приложение, то вам показывается как движется автомобиль. На самом деле данные не реалтайм, а построены на фильтре Калмана. Слава богу что они додумались его использоваться. Но вместо того, чтобы открывать сокет и передавать в него данные, водительское приложение через HTTP запрос передает свои координаты, а сервер ему возвращает поллинг интервал когда сообщить в следующий раз.
В итоге получаем, что водитель уже на месте, а у пользователя по фильтру калмана водитель проехал дальше на пару километров вперед. А все потому что сервер ответил водителю передать свои координаты через 3 минуты, допустим. И это самый банальный пример.
А вы тут про guuid и инкременты.
Почему с помощью расширения? — Не хочется снимать с поддержки конфигурацию.
Задача информировать внешние интеграционные системы об изменениях в базе, нежели регулярно опрашивать.