L. Fregimus Vacerro (fregimus) wrote,
L. Fregimus Vacerro
fregimus

Category:

Практическая задача по хранению уймы временных результатов

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

Имеется некоторое число агентов, числом порядка десятков. Каждый агент вступает, скажем, в разговор, и в процессе записывает некоторый журнал, текстовую информацию. Для каждой строки мы записываем время, целое число — код события и, собственно, текст, до 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? Это то, что мы ищем, или нет?
Tags: computer, techne
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic
  • 31 comments