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

Question

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

проблема.
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) Я думаю, что в решении будет компонент метаданных, который будет отслеживать, кто владеет столбцами и чтокаждый столбец представляет и исходную исходную систему.

Спасибо за чтение и заранее спасибо за любые мысли.

Answer 1

SQL

При использовании инструментов уровня Teradata может быть возможным решение на основе SQL.Я недавно наткнулся на статью о дизайне базы данных , в которой обсуждалось «моделирование якорей» .

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

Подмножества могут основываться на сопровождающем или некоторых другихкритерии.XML set / get будет для каждого подмножества / записи (а не для глобальной записи).Все подмножества для заданных записей могут быть составлены и кэшированы.Дополнительные подмножества могут быть созданы для метаданных, поисковых индексов и т. Д., И они могут запрашиваться независимо.

NoSQL

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

Production NoSQL

. Не так много, есть несколько крупных компаний, использующих NoSQL в масштабируемых средах, таких как Google Bigtable .Похоже, идеальный инструмент для:

6) поиск одной записи должен быть возвращен в течение секунд7) Система должна поддерживать максимум 1 миллион запросов в час.

Bigtable доступен (насколько мне известно) только через AppEngine .Другие, подобные технологии перечислены здесь .

Другие мысли

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

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

Answer 2

Пара мыслей:

1) наше предприятие LDAP стало «мастером контактов», заполненным годами устаревших данных и неиспользованными и не поддерживаемыми атрибутами.на самом деле не технологическая проблема.У вас также будет эта проблема с новой системой, LDAP или нет.

"LDAP ... не масштабируется"

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

Может быть, вам нужна новая система LDAP, которой проще управлять / в которой есть лучшие инструменты администратора?

Answer 3

Возможно, вы захотите взглянуть на модель партии Лена Сильверстона.Вот ссылка на его книгу: http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237.

У меня нет опыта построения чего-либо в этом масштабе, хотя я думаю, что думать об этом как о 500 тыс. Строк х 500–1000 столбцов звучит немного смешно.