Я хотел бы перейти от подхода SQL к подходу ключевого значения, потому что я имею дело с «большими данными» и хотел бы извлечь выгоду из таких систем, как DynamoDB, Riak или Кассандра.
Это довольно просто, когда данные не связаны между собой, поэтому есть подход на основе документов (первичный ключ + данные, но без отношений).
Буду признателен за любой теоретический или академический вклад в моделирование моих данных.
Я использую NoSQL последние 4 года, и это именно то, что я думаю, чему я научился ... мои личные золотые правила.
Предпосылка: в мире SQL любая возможная связь между данными, любой проблемой или ситуацией, с которой приходится иметь дело, часто дает точный ответ, учитывая как возраст, так и «уникальность» продукта - люди, пришедшие из этого » perfect world "попробуйте взглянуть на no-sql таким же образом, но здесь любая проблема может иметь множество решений (или не иметь решения), основанные как на потребностях приложения, так и на продукте, который вы используете.
Прежде чем писать модель, подумайте над запросами. Термин "ориентированный на запросы" действительно подходит для контекста - углубляйтесь в анализ, и чем больше вы будете знать о том, как вы будете запрашивать данные, тем лучше будет результат.
Денормализовать. Не думайте о том, что «таблица содержит определенные данные», а скорее о том, что «таблица отвечает на несколько запросов». - поэтому ваши данные (или другое подмножество ваших данных) могут повторяться в разных таблицах. Это норма и способ избежать объединений и отношений.
Это неявно расширение первых двух: не думайте, что «чем меньше таблиц, тем лучше будет дизайн» - чем больше запросов и, вероятно, тем больше будет таблиц.
Изучите свой продукт - каждая система предлагает разные функции - некоторые из них будут предлагать вам «сортировку данных» бесплатно, некоторые другие могут предлагать коллекции, обратные вызовы, триггеры и т. Д. - поэтому модель может сильно отличаться от одного продукта к другому
Учитывайте свои потребности и возможности - иногда вам придется выбирать, например, создавать ли новую таблицу с данными, отсортированными по-другому, или сортировать данные на стороне клиента. Нет правильного ответа. Если у вас мало места на диске или данные для сортировки представляют собой небольшие наборы, вы можете выбрать способ, если у вас мало «вычислительной мощности», вам лучше выбрать другой
Помните, что NoSQL означает не «Нет SQL», а «Не только SQL». Вы также можете представить свою схему как гибрид (я думаю, что https://mariadb.org/ предлагает такое решение ) или помните, что вы можете поместить слой Hive / Shark / Pig для выполнения более сложных "внутренних запросов"
Если вы выберете Cassandra, немного изучив продукт, посмотрите здесь:
HTH, Карло
