Регистрация данных без использования обычной базы данных SQL?

Question

В настоящее время я регистрирую каждый «сбой» на своем сайте (вход в систему / регистрация / и т. Д.) В базу данных, чтобы я мог отслеживать, что доставляет неудобства моим пользователям - или какие ips / пользователи делают подозрительные вещи.

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

Я думалчто, возможно, мне следует попытаться сохранить часть нагрузки, которую моя база данных берет на себя из всей этой регистрации, и поместить данные в нечто вроде memcached или couchdb.Однако я не уверен, как можно запросить данные в наборах результатов.

Как можно использовать хранилище значений ключей или базу данных документов для мониторинга журналов и отслеживания отношений между действиями? И стоит ли даже добавлять другое хранилище данных на сервер или просто удерживать базу данных от его обработки?Я упоминаю memcached и couchdb, потому что оба могут при необходимости использовать очень мало оперативной памяти (в отличие от mongodb и redis).

Позвольте мне привести пример.IP 0.0.0.0 не удалось войти в систему 37 раз за 3 часа (каждый записан), также не удалось сбросить пароль для действительного электронного письма 84 раза за 2 часа.Благодаря моим логам я теперь могу исследовать (и блокировать) этого бота.С другой стороны, я вижу, что из 5827 зарегистрированных пользователей - 2188 неудачных попыток регистрации.Это говорит мне о том, что с моей формой регистрации что-то не так, что заставляет многих людей отказывать в форме хотя бы один раз.

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

Answer 1

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

Как только данные журнала находятся на диске, вы можете скопировать их на другой компьютер для анализа и анализа, используя любой набор инструментов, который вам нужен, и если вы хотите использовать хранилище документов, это место для его представления. Вам не нужно обременять ваши передовые производственные машины этой работой.

Answer 2

Итак, если я вас правильно понимаю:

• В вашем хранилище данных журналирования находится 50-70 миллионов записей.
• Задержка чтения не является критической (менее секунды), поскольку вы проверяете ее ежедневно, основываясь на таких триггерах, как аномалии сайта или запросы клиентов.
• Ваша база данных журналов и база данных OLTP в настоящее время находятся на одном сервере.
• Основываясь на вашем профиле и ваших ответах выше, я предполагаю, что вы используете MySQL, а не MSSQL.
• Я также предполагаю, что, поскольку вы ограничиваете свою базу данных журналов в течение семи дней, резервное копирование не является чем-то, что вас волнует (так сильно) при этом.

Несколько вещей о нереляционных решениях и документно-ориентированных магазинах, в частности: 1. Они не требуют от вас быть Facebook или Twitter. Настройка как для MongoDB, так и для CouchDB не должна быть обязательной для предприятия. 2. Они хорошо подходят для хранения данных журнала и событий. 3. И CouchDB, и MongoDB будут использовать столько памяти, сколько доступно для кэширования их индексов. 4. MongoDB предлагает «ограниченную» коллекцию, которая устанавливает ограничения на размер хранимых данных, а затем сворачивает строки / сообщения данных по мере их устаревания. Это кажется особенно подходящим для ваших потребностей, если вы внедряете MongoDB, так как не требует от вас непрерывного выполнения тяжелых удалений в вашей реляционной базе данных. 5. Интерфейс запроса существенно отличается от SQL, к которому вы привыкли. Оба могут принимать основанные на JSON документы запросов и возвращать результаты. IMHO, библиотеку функций MongoDB легче подобрать для разработчика.

Тем не менее, вот загвоздка: 1. Если вы не собираетесь устанавливать его на другом компьютере, вы не решите проблему загрузки. Нереляционные хранилища не так эффективны с диском или памятью, как ваш экземпляр MySQL. 2. Оба хранят данные в формате JSON. Если ваш компонент журналирования не говорит на JSON, вам нужно его кодировать. 3. Если вы полагаетесь на регулярные выражения, Couch не сделает этого. Монго будет.

Миндас прав, когда говорит, что нереляционные хранилища достигают своего масштаба, вырывая фундаментальные аспекты реляционных хранилищ: транзакции ACID, строго типизированные данные, четко определенные структуры, оптимизированные отношения соединения, эффективное хранение данных.

Тем не менее, такие вещи, как записи журнала с конечным сроком службы, вариантное содержимое и плоская структура, идеально подходят для хранилища документов и не требуют такой большой инфраструктуры. Я потратил буквально десятилетия, создавая реляционные структуры, которые хорошо работают на 90% системы, а остальное - через ряд обходных путей.

Для меня нереляционные хранилища дают возможность сохранять плоские данные в виде схемы в более естественной форме.

Надеюсь, это поможет вам найти путь, который вам подходит.

Answer 3

Хранилища ключей или баз данных на основе документов не являются панацеей . Если вы хотите поиграть с ними просто для удовольствия, тогда это нормально, но если вы хотите сделать это, чтобы сэкономить часть загрузки моей базы данных , я настоятельно рекомендую не тратить ваше время. Позвольте мне объяснить.

Во-первых, вы должны понимать, что эти структуры данных в последнее время стали популярными из-за необходимости масштабируемости для сверхбольших сайтов (LinkedIn, Facebook и т. Д.). И что еще более важно, они предоставили эту часть масштабируемости по цене удобства.

Думайте об этих хранилищах данных нового поколения как об урезанных базах данных, которые не имеют связей между таблицами и уровня SQL. Таким образом, записи становятся дешевыми, так как нет необходимости беспокоиться о зависимых данных. Но тогда чтение может стать дорогим (если у вас нет индекса), так как вам приходится иметь дело со сложностью O (n). Это нормально для случаев, когда идентификатор ключа всегда известен, или для заданий постобработки, где время отклика не имеет большого значения. Или вы можете выполнять быстрый поиск с индексом для плоского документа, но не ожидайте, что внешние ключи будут обрабатываться автоматически.

Если бы вы регистрировали данные в хранилище kv, вы могли бы решить проблему запроса, зарегистрировав всю запись в хранилище kv и записав ключи (идентификаторы) для случаев «сбоя» отдельно (например, могли быть сохранены под специальным ключом) , После этого вы можете найти поврежденные записи в O (1) раз. Нужно быстро искать разные случаи (не удалось сбросить пароль, не удалось зарегистрироваться)? Нет проблем, просто добавьте еще один «специальный» ключ и переиндексируйте все существующие данные :) Вы были предупреждены об утрате удобства!

Если бы вы регистрировали данные в хранилище документов, вы могли бы извлечь выгоду только в том случае, если ваши записи журнала плоские (ненормализованные). В противном случае я не вижу, как вы могли бы хранить данные в них, в первую очередь. Затем вы можете создать индексы на основе типа события и запроса по нему. Однако я не вижу большой разницы / улучшений по сравнению с тем, что вы имеете сейчас.

Но подумай об этом. Вероятно, вы потратите недели (если не месяцы) на переписывание, отладку и тестирование существующего кода регистрации. Вам придется определить различные стратегии резервного копирования. Вам будет больно объяснять это своим системным администраторам, боссам и т. Д. Или вы можете купить SSD-диск стоимостью в несколько сотен долларов и добиться таких же, если не лучше, результатов.