Большое приложение чата Mysql db для хранения сообщений 1 строка на сообщение или добавление всей цепочки к 1 длинному текстовому файлу

Question

Большое приложение чата Mysql db для хранения сообщений 1 строка на сообщение или добавление всей цепочки к 1 длинному текстовому файлу

0

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

Вариант 1. Традиционный подход для вставки одной строки в сообщение/ответ. Просто вставляя в db, который не просматривался ранее, однако перестройка
для потока чата потребуется ORDERBY

Вариант 2. Или добавить каждое сообщение в одно поле сообщения. Быстрее будет выбирать, поскольку для ORDERBY не будет необходимости. Однако при каждом новом сообщении будет поиск 1-го

Также с опцией 2 было бы меньше общих строк в db

Есть идеи?

SeanAA 25 фев. 2018, в 14:36

Источник

1

Вариант 3 и только правильный: две таблицы «разговор» и «один предмет»
Jacek Cz 25 фев. 2018, в 13:19

Теги:

mysql

database

sql

bigdata

chat

2 ответа

1

Это полностью зависит от того, что вы хотите делать с этим полем. Однако почти во всех случаях первое решение - отдельная строка для каждого разговора - это правильный подход.

Вы бы хотели использовать второй подход - одно поле для всех из них - если вы рассматривали разговор как "blob". То есть, если вы не хотите выбирать конкретные сообщения, искать в сообщении и т.д. По существу, столбец будет архивом сообщений, а скорее чем-то полезным для другого столбца.

Я должен также добавить, что в разговоре хранение сообщений в одном столбце теряет информацию о том, когда было отправлено сообщение и кто его отправил. Конечно, вы можете попытаться инкапсулировать это, скажем, с помощью столбца JSON. Но зачем беспокоиться? SQL уже имеет хорошие механизмы для представления такой информации.

Gordon Linoff 25 фев. 2018, в 11:43

0

спасибо за ваш вклад, Гордон. Приложение будет работать в обоих направлениях, как временные метки, встроенные в сообщение и отображаемые с использованием JS. Я искал специально для ввода, касающегося БД и производительности обоих вариантов
SeanAA 25 фев. 2018, в 13:19

Ещё вопросы

Вариант 3 и только правильный: две таблицы «разговор» и «один предмет»
спасибо за ваш вклад, Гордон. Приложение будет работать в обоих направлениях, как временные метки, встроенные в сообщение и отображаемые с использованием JS. Я искал специально для ввода, касающегося БД и производительности обоих вариантов

Gene S · Accepted Answer · 2018-02-26T14-50-00.000Z

Я участвовал в проектах двух крупных (в 10-х миллионов активных пользователей) систем. Оба использовали реляционные БД для хранения, один использовал MySQL. В обоих случаях было сохранено одно сообщение в строке. Индексирование [thread_id, message_timestamp | message_sequential_number | message_auto_increment_id] [thread_id, message_timestamp | message_sequential_number | message_auto_increment_id] [thread_id, message_timestamp | message_sequential_number | message_auto_increment_id] отлично подходит как для загрузки, так и для заказа.

Имейте в виду, что разговоры могут вырасти до нескольких мегабайт. Если вы храните весь разговор в одной строке, вам придется читать/записывать всю вещь в каждое новое сообщение или хранить всю память в памяти, чтобы в большинстве случаев показывать, возможно, 50 последних сообщений. Легко 200x неэффективность.

С другой стороны, если вы чувствуете себя авантюристами, взгляните на Кассандру. Он предназначен для эффективного хранения всего разговора в одной записи.

Отличное понимание, спасибо за ваши мысли, я решил выбрать вариант «одно сообщение в строке» ...