данные полуструктурированного хранилища/запроса

Question

У нас было приложение, написанное на Perl, которое создает сложную структуру данных для нашего подписчика (у нас есть более чем 4 миллиона абонентов). у каждого подписчика есть некоторые поля conmen, которые присутствуют во всех них, а некоторые другие подписчики не хватает.

Данные выглядит следующим образом:

%subscribers = { 
    "user_001" = { 
     "name" => "sam", 
     "age" => "13", 
     "color" =>['red','blue'] 
     "item"=>{ 
      "old" =>['PC','pen'], 
      "new" =>['tap','car'] 
     }, 
    "user_002" = { 
     "name" => "ali", 
     "age" => "54", 
     "color" =>['red','null','green'] 
     "item"=>{ 
      "old" =>['phone','TV'] 
     }, 
    "user_003" = { 
     "name" => "foo", 
     "age" => "02", 
     "item"=>{ 
      "old" =>[''] 
     }, 
     .... 
    } 
} 

наши данные более неприятный и сложный

Сейчас мы пытаемся сохранить эти данные в БД, то сделать некоторые запрос в них, как получить пользователь, что есть новые «TAPs» в предмете или возраст больше 30 лет.

Что нам нужно знать: Каков наилучший способ хранения данных (как MySQL или Oracle db not option), нам нужно что-то для данных полуструктуры. Как делать эти запросы, принимая во внимание преформацию.

Мы требуем заголовка, чтобы начать наш поиск (и да, мы сделали домашнее задание с помощью Google^_ ^).

BR, Хосен

Answer 1

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

1. будет ли новый выбор технологии стал авторитетным хранилище данных, или только то, что вы хотите на болты с минимальными изменениями, чтобы помочь вам запросы службы?
   • Если вы просто хотите быстро закрепить новый API для обслуживания запросов, то новые технологии NoSQL, такие как MongoDB (с отличным perl driver), станут жизнеспособным вариантом (и вы можете прорвать хеш-файл perl, как вы описали с помощью маленький код). Если вы используете его только как кеш (возможно только для чтения), вы смягчаете все проблемы с долговечностью и избегаете дорогостоящих усилий по очистке/проверке/нормализации данных, чтобы быстро получить доступ к 80% -ному решению.
   • Если вы хотите что-то долговечное, чтобы заменить ваше текущее хранилище данных, это правда, что существуют опции, отличные от SQL RDBMS. Хранилища XML, такие как eXistDB, очень эффективны, если вы уже работаете с экосистемами XML, и ваши данные соответствуют парадигме документа и объекта, где XQuery/XPath имеет смысл (для него есть даже RPC RPC thing). Стоит взглянуть на коммерческих продавцов, например, MarkLogic или EnterpriseDB, если у вас есть время и достойный бюджет. Если ваши данные действительно беспорядочно и могут быть эффективно смоделированы как график сущностей и отношений, возникает соблазн рассмотреть такие вещи, как SparkleDB, Neo4j или Virtuoso, однако в моем ограниченном доступе к этим вещам, хотя у них есть большой потенциал для обслуживания в противном случае невозможных или сложных запросов/аналсисов, они создают ужасное место для изучения и управления вашими основными бизнес-данными.
2. Какие запросы, аналитики или отчеты вы хотите сделать? Это определит, сколько потребуется очистки данных и нормализации.Ответ на этот вопрос поможет вам сфокусировать свой выбор:
   • Если вы считаете, что в конечном итоге выполните очистку данных/проверку/трансформацию, чтобы реализовать свой окончательный выбор и сделать запрос данных, вы также можете использовать традиционный SQL базы данных, но изучите ее использование по методу «NoSQL» (есть много советов/сравнения out there).
   • Если вы надеетесь избежать большого количества очистки/проверки данных/нормализации из-за нехватки времени или бюджета, я боюсь, что для более зрелых решений XML/RDF/SPARQL потребуется 10-кратное инженерное усилие для проектирования и создать рабочую систему, построенную вокруг грязных данных, чем просто очистить ее должным образом в первую очередь.
   • Если у вас действительно беспорядочные, неоднородные данные (особенно, когда вам нужно постоянно импортировать из сторонних сторон, над которыми вы не контролируете, и вы хотите избежать постоянного усилия по очистке данных), оставив ваши грязные данные «как есть», наносит вам страх. С одной стороны (с точки зрения стоимости, а также мощности запроса/выразительности и точности) у вас есть решения XML/RDF/SPARQL, упомянутые ранее. В более дешевой/более быстрой/простой (возможно, слишком простой во многих случаях) у вас есть соперники, такие как MongoDB, Cassandra и CouchDB (это далеко не полный список, и они имеют разные уровни поддержки perl или качества клиентов perl).