тематические исследования или примеры высокопроизводительных сервисов с высокодинамичными данными
Я ищу некоторые архитектурные идеи по проблеме на работе, которую мне, возможно, придется решить.
проблема.
1) LDAP нашего предприятия стал «мастером контактов», заполненным годами устаревших данных и неиспользованными и не поддерживаемыми атрибутами.
2) руководство решило, что LDAP больше не будет служить телефонной книгой компании. только для авторизации.
3) компания имеет контактные данные о людях в сотнях разных источников. нам нужно удалить весь мусор из LDAP и предоставить другим приложениям централизованное хранилище для хранения всех этих данных о человеке.
идеальная цель
1) иметь один источник для хранения всех различных атрибутов человека
2) у компании, вероятно, есть информация о 500 тыс. Человек (прочитано 500 тыс. Строк)
3) Я считаю, что у этих людей может быть от 500 до 1000 необязательных атрибутов. (прочитайте 500+ столбцов)
4) данные будут в основном установлены / получены через xml через jms (эта инфраструктура уже существует)
5) отдельные группы внутри компании могут «владеть» колоннами. только им будет разрешено писать в свои столбцы, они будут нести ответственность за чистоту данных.
6) поиск за одну запись должен быть возвращен за секунды
7) система должна поддерживать максимум 1 миллион запросов в час.
8) первичная цель заключается в предоставлении предприятиям данных в режиме реального времени, а отчетность - вторичной цели.
9) мы магазин java, oracle, terradata. Мы ваш типичный большой IT-магазин.
мои мысли:
1) Первоначально я думал, что LDAP может работать, но он не масштабируется при добавлении новых столбцов.
2) моей следующей мыслью было какое-то решение без SQL, но из того, что я прочитал, я не думаю, что не могу получить необходимую мне производительность, и она все еще относительно новая. Я не уверен, что смогу заставить моего менеджера подписать что-то подобное для такого важного проекта.
3) я думаю, что в решении будет компонент метаданных, который будет отслеживать, кому принадлежат столбцы и что представляет каждый столбец, а также исходную исходную систему.
Спасибо за чтение и заранее спасибо за любые мысли.
3 ответа
SQL
С инструментами уровня Teradata может оказаться возможным решение на основе SQL. Некоторое время назад я наткнулся на статью о проектировании базы данных , в которой обсуждалось «моделирование привязки» .
По сути, идея состоит в том, чтобы создать единую, глупую, синтетическую таблицу первичных ключей, в то время как все реальные или метаданные находятся в других таблицах (подмножествах) и присоединяются посредством внешнего ключа + соединения .
Я вижу двойную выгоду от этого дизайна. Во-первых, вы можете более легко разделить хранилище данных по организационным причинам или по соображениям производительности. Во-вторых, вы создаете дополнительные строки только для записей, которые содержат данных в любом заданном подмножестве, поэтому вы используете меньше места, а индексирование и поиск выполняются быстрее.
Подмножества могут быть основаны на критериях сопровождающего или некоторых других критериях. Набор / получение XML будет для каждого подмножества / записи (а не для глобальной записи). Все подмножества для заданных записей можно объединять и кэшировать. Дополнительные подмножества могут быть созданы для метаданных, поисковых индексов и т. Д., И их можно запрашивать независимо.
NoSQL
NoSQL кажется похожим на LDAP (по крайней мере теоретически), но преимущество хорошего инструмента NoSQL будет заключаться в большей абстракции метаданных, управления версиями и организации. Фактически, из того, что я прочитал, кажется, что хранилища данных NoSQL предназначены для решения некоторых проблем, которые вы подняли в отношении масштабирования и слабо структурированных данных.Есть хороший вопрос по SO относительно хранилищ данных .
Производственный NoSQL
В автономном режиме есть несколько крупных компаний, использующих NoSQL в масштабируемых средах, таких как Google Bigtable . Кажется, это идеальный инструмент для:
6) поиск одной записи должен возвращаться за доли секунды
7) в пике система должна поддерживать 1 миллион запросов в час.
Bigtable доступен (насколько мне известно) только через AppEngine . Другие похожие технологии перечислены здесь .
Другие мысли
Увеличенное изображение выглядит более или менее одинаково, независимо от технологии, которую вы решите использовать. Например. разделите хранилище, составные представления, представления кеша, прикрепите куда-нибудь метаданные, чтобы вы могли что-то найти.
Целевые характеристики производительности потребуют некоторого кэширования и / или оптимизации на основе реальных шаблонов использования. Независимо от того, какое решение вы выберете, вы, вероятно, не сможете решить его на этапе проектирования.
Пара мыслей:
1) наш корпоративный LDAP стал «мастером контактов», заполненным годами устаревших данных и неиспользуемых и неподдерживаемых атрибутов.
На самом деле это не технологическая проблема. У вас также будет эта проблема с новой системой, LDAP или нет.
«LDAP ... не масштабируется»
Существует множество огромных систем LDAP. LDAP, безусловно, является темным искусством, но я готов поспорить, что в этой ситуации он масштабируется лучше, чем любой эквивалент SQL. Не говоря уже о том, что LDAP является стандартом для такого рода информации, и поэтому он доступен из миллиардов различных систем.
Может быть, вы ищете новую систему LDAP, которой проще управлять / с лучшими инструментами администрирования?
Возможно, вы захотите изучить "Модель партии" Лена Сильверстона. Вот ссылка на его книгу: http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237.
У меня нет опыта построения чего-то в таком масштабе, хотя я думаю, что мысли о том, что это 500k строк x 500 - 1000 столбцов, звучат немного нелепо.