Найкращий спосіб зберігати повідомлення чату в базі даних? [зачинено]


82

Я створюю додаток для чату, і я хочу, щоб була повна історія всіх повідомлень, коли-небудь надісланих у чаті. На даний момент я зберігаю кожне повідомлення як один рядок у таблиці, яка називається "повідомлення". Я усвідомлюю, що ця таблиця може зрости величезною, оскільки навіть такі маленькі повідомлення, як "Привіт", матимуть власний запис бази даних.

Хтось може порекомендувати більш масштабоване рішення MySQL? Я не вимагаю, щоб окремі повідомлення були доступними для пошуку, редагування чи видалення. Чи можна всю розмову зберігати в одному величезному полі?

Хотіли б почути ваші ідеї!


12
якщо ці повідомлення не потрібно шукати чи редагувати, немає сенсу зберігати їх у базі даних
ajreal

21
Я б порадив починати легко, мислити просто, використовувати реляційну базу даних, і якщо масштабування стає проблемою, вирішуйте це! Занадто багато людей піклуються про сценарії, яких ніколи не буде, оскільки вони витрачають занадто багато часу на створення ідеальної інфраструктури, і вони не матимуть часу зосередитись на тому, що важливо.
whirlwin

Відповіді:


48

У збереженні всієї історії у базі даних немає нічого поганого, вони готові до таких завдань.

Насправді ви можете знайти тут у Stack Overflow посилання на приклад схеми для чату: example

Якщо ви все ще турбуєтесь про розмір, ви можете застосувати деякі оптимізації до групових повідомлень, наприклад, додати буфер до вашої програми, який ви натискаєте лише через деякий час (наприклад, приблизно 1 хвилину); таким чином, ви уникнете повідомлення лише з 1 рядка


15

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

Просто додайте розмову до текстового файлу (1 файл на користувача \ розмову). і мають структуру каталогів / файлів

Ось спрощений вигляд структури файлу:

chat-1-bob.txt
        201101011029, hi
        201101011030, fine thanks.

chat-1-jen.txt
        201101011030, how are you?
        201101011035, have you spoken to bill recently?

chat-2-bob.txt
        201101021200, hi
        201101021222, about 12:22
chat-2-bill.txt
        201101021201, Hey Bob,
        201101021203, what time do you call this?

Тоді вам потрібно буде зберегти лише ідентифікатор користувача, ідентифікатор розмови (guide?) Та посилання на ім'я файлу.

Я думаю, вам буде важко отримати більш просте масштабоване рішення.

Ви також можете LOAD_FILEотримати дані, див.: Http://dev.mysql.com/doc/refman/5.0/en/string-functions.html

Якщо у вас є потреба відновити розмову, вам потрібно буде поставити значення (час і дату) поруч із надісланим повідомленням чату (у файлі), щоб дозволити вам об’єднати та відсортувати файли, але на даний момент це, мабуть, гарна ідея розглянути можливість використання бази даних.


1
Це звучить блискуче. Хтось може заперечити цей аргумент?
Поїздка

76
Запис у файл - це жахлива ідея. У більшості середовищ або кластера на стороні сервера ви навіть не повинні гарантувати, що ваш другий запит потрапив на той самий сервер, що і файл. Запис файлової системи надзвичайно повільний і пов'язаний з операціями вводу-виводу. На жаль, я не можу повірити, що це набрало стільки голосів.
Енді Фусняк,

6
вибачте, я насправді відповідав на питання, не складаючи вигаданих сценаріїв. На даний момент повідомлення зберігаються в базі даних, то чому чому проста файлова система пише набагато повільніше. Також прочитайте мою відповідь 1 файл на користувача \ бесіду !!! (на вашому вигаданому кластері я встановив FSA-SAN). Вимога OP, на мій погляд, належить до файлу.
Кевін Бертон,

5
Запис і читання у файл вимагає великих ресурсів. Я думаю, що використання бази даних будь-якого типу має допомогти зменшити затримку ресурсів. Зрештою, бази даних також зберігають цю інформацію для подання (трохи інакше). Я думаю, що дана ідея є фантастичною для зберігання заархівованих чатів або чатів старше 1 року чи близько того. Але тут ніщо не зрівняється з простим db.
Джей Патель - PayPal,

3
OP чітко говорить у базі даних, крім цієї жахливої ​​ідеї, це не відповідає на питання
Lyoneel

2

Ви можете створити базу даних для x розмов, яка містить усі повідомлення цих розмов. Це дозволить вам додавати нову базу даних (або сервер) кожного разу, коли x перевищує. X - це кількість розмов, які підтримує ваша інфраструктура (залежно від вашого обладнання, ...).

Проблема все ще полягає в тому, що в одній і тій же базі даних можуть бути великі розмови (з великою кількістю повідомлень). наприклад, у вас є база даних A і база даних B, кожна з яких зберігає, наприклад, 1000 розмов. Можливо, на сервері А є набагато більше "великих" розмов, ніж на сервері Б (оскільки це вміст, створений користувачем). Ви можете додати базу даних "master", яка містить пошук, на якій базі даних / сервері можна знайти одиничні розмови (або у вас є схема для призначення бази даних з хешу / модуля або чогось іншого).

Можливо, ви можете знайти реальні архітектури, які мають справу з одними і тими ж проблемами (можливо, ви не першими), і які вже вирішені.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.