?

Log in

No account? Create an account

Previous Entry | Next Entry

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

Имеется некоторое число агентов, числом порядка десятков. Каждый агент вступает, скажем, в разговор, и в процессе записывает некоторый журнал, текстовую информацию. Для каждой строки мы записываем время, целое число — код события и, собственно, текст, до 1000 символов (в среднем 150). За 2 минуты эксперимента агент выдает где-то таких строк 200-300. Кроме того, записывается код агента и код разговора. Информация хранится 2 месяца, затем ее можно стирать. Собственно, вот и все — один последовательный файл на всех или одна таблица в базе данных.

В части запросов к хранилищу: нам хочется получать весь журнал одного агента (один агент производит единицы или десятки разговоров, и исчезает навсегда), одного разговора или запрашивать информацию по тому самому коду события. Некоторые из кодов «более важны» (они известны заранее, и их коды отрицательные); более важные записи всегда просматриваются человеком, ежедневно, несколько раз в день. Однако, запросы по другим кодам тоже приходится делать, но реже.

Сейчас это все записывается в таблицу в БД. К сожалению, вставлять записи мы успеваем (BULK INSERT), а вот удалять уже не всегда получается, DELETE просто не успевает их удалять с нужной скоростью, и эта зараза растет. Сейчас она живет на отдельном диске в 1ТБ на машине с 2 зеонами и 32 ГБ оперативной памяти. Мы добавим SSD для tempdb, но это, пожалуй, все, что мы смогли придумать по части железа. Сервер MS SQL Server 2008 на OS Windows Server 2008 R2. Все это как бы работает, только медленно немного: запрос на один журнал агента выполняется минуту-другую, а, например, всех отрицательных («важных») кодов за сегодня — минут от 8 до 25, в зависимости от погоды в Атлантике и личного расположения сервера к запрашивающему (других факторов не пока выявлено). Файлы занимают где-то 200-300 ГБ на диске, если сложить индексы, данные и database logs вместе. И пухнет потихоньку: мы и машин с агентами добавляем, и, как я уже говорил, не за два месяца там данных, а уже за 3, и все больше делается.

Надо сказать, что, когда мы эту страхолюдию запускали, в больших базах данных мы не очень понимали, но теперь понимаем куда больше — многие простые решения уже сделаны. Это чтобы показать уровень владения предметом: совсем не специалисты, изучивших всю эту напасть на своем горбу.

Возможно, существуют более эффективные решения, чем СУБД, учитывая простоту хранимых данных (нет модификации, только вставка/удаление; нет реляций, одна-единственная таблица), но мы их не нашли. Не думаю, что с такой проблемой столкнулись мы одни. Если знаете, как такие вещи решают — научите витающих в облаках теоретиков, как с ними справляются, а?

Доб. Кто-нибудь имел дело с Apachе Cassandra или Hypertable? Это то, что мы ищем, или нет?

Comments

aamonster
Sep. 7th, 2010 09:44 am (UTC)
Как это сделать не через СУБД - понятно. Но это - шанс в будущем наступить на грабли (не хватит функционала, будет что-то прикручено, потом ещё что-то, потом сменятся разработчики, и однажды окажется, что поддерживающий всё это человек не разбирается в системе и всё сломает).

Так что, может, повыяснять возможности разных СУБД?
fregimus
Sep. 7th, 2010 10:20 am (UTC)
А как сделать? Мне вот не понятно совсем.

Повыяснять — не знаю, как, ески только их все не перепробовать. Потому я пост этот и затеял.
aamonster
Sep. 7th, 2010 11:01 am (UTC)
Не через СУБД:
1. Файл (или куча файлов, если есть ограничения файловой системы) с фиксированным размером записи.
2. Файл со списком свободных записей.
Соответственно, добавление и удаление записи - элементарная операция (Для добавления - взять номер из списка 2, перезаписать. Если нет свободной - увеличить файл 1. Для удаления - внести в список 2. Ну и поправить индексы 3).
3. Индексы для поиска. Тут много возни, но по вашей задаче вроде всё можно свести к связным спискам по каждому агенту, разговору и коду события (агентов, разговоры и коды для простоты хранить в БД - по каждому агенту/разговору/коду голову списка). Ссылки списков можно хранить либо в самих записях (по 3 ссылки в каждой - не помешает, либо в отдельных файлах - это позволит организовать ещё кое-какие оптимизации)

Но всё это - типичный закат солнца вручную. Явно какие-то БД должны давать возможность настройки, обеспечивающей сопоставимое (или более высокое) быстродействие. Но в БД я не разбираюсь.
fregimus
Sep. 7th, 2010 05:17 pm (UTC)
Ну понятно — фактически, ISAM реализовать самому. Это уж только если совсем прижмет.

Profile

oak
fregimus
L. Fregimus Vacerro

Latest Month

August 2018
S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 

Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow