Предложение базы данных для социальной сети / сообщества базы знаний?


12

Я ищу различные типы баз данных и СУБД для нового проекта, который я хочу начать летом.

Я построил системы в MySQL и PostgreSQL, теперь я хочу расширить свои знания и опыт в области баз данных.

Мой проект будет чем-то вроде социальной сети / совокупного знания. (еще не разработали термин, чтобы описать его).

Я смотрю на:

  • Кассандра (использовать свой собственный тип языка запросов); Кажется, это хорошо для многофункционального контента и обеспечения высокой производительности выполнения запросов. Однако я не слишком заинтересован в этом, потому что для работы требуется среда Java, и я предпочел бы не иметь ничего общего с Oracle.
  • MongoDB (noSQL тип СУБД); отличная масштабируемость, однако вы теряете все возможности, уже доступные на проверенном языке SQL, такие как запросы бизнес-информации.

Требования к системе:

  • Текст данных , даты, время, XML, маленькие целые, BLOB,
  • Структура / поведение : нормализованная 3NF, не в реальном времени, реляционная, масштабируемая, устойчивая
  • Окружающая среда: Unix / Linux, нет JAVA !, желательно работать на C

Мне было интересно, не могли бы вы указать мне какие-либо другие системы баз данных, которые я должен изучить.

Я также взглянул на объектно-реляционные базы данных, мне очень понравилась идея их работы с объектами PHP (PDO), однако их производительность кажется немного плохой.

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

Благодарность


3
Если вы хотите нормализовать 3nf, вам нужно создать реляционный магазин. Период.
JNK

2
Я бы не стал выбивать Java только потому, что это «Oracle». Используйте правильный инструмент для работы. Если бы Java был лучшим инструментом, я бы использовал его. Если C - правильная работа, используйте ее. Сосредоточьтесь на том, что каждый инструмент дает вам, плюсы и минусы. Примите хорошо обоснованное решение (то же самое со стороной DB), а не на основе чувств.
Крис Олдрич

Ответы:


4

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

Бесплатные вещи

  • CouchDB - одна из первых баз данных NoSQL, мощная система отображения / сокращения запросов, высоко распределенная и отказоустойчивая. Один из лучших претендентов на NoSQL.
  • Hyperdex - очень новая, распределенная хеш-таблица с возможностями поиска.
  • Riak - распределенная хеш-таблица, достойная некоторого уважения.

Странные бесплатные вещи

  • Metakit - больше встроенной базы данных, такой как SQLite, но не основанной на SQL, поэтому более процедурной.
  • FramerD - очень похож на классическую «сетевую» базу данных, очень ориентированную на указатели. Возможно мертвый?
  • Магма - Smalltalk OODBMS. Круто, но не очень хорошо задокументировано.

Несвободные вещи

  • AllegroGraph - RDF (граф) база данных, поддерживает SPARQL. Лисп вкус.
  • Caché - гибридная реляционная / OO база данных, изначально основанная на MUMPS (IIRC).
  • Объективность - одна из последних нескольких действительно больших OODB. Очень мощный, впечатляющий и дорогой.
  • VoltDB - Масштабируемая в основном реляционная база данных. Поддерживает «самый» SQL. Очень новый Я думаю, у них тоже есть версия сообщества.

Вывод

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

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

Мысленный эксперимент для вас

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

Должно быть очевидно, что было бы хуже потерять данные. Почему все ваши пользователи восстанавливают все эти данные? Подумайте обо всех потерянных маркетинговых данных, как Facebook на самом деле зарабатывает деньги. И есть множество предпринимателей, которые слюноотделают при возможности заставить людей использовать свой клон Facebook - теперь все те лишенные права голоса бывшие пользователи Facebook будут там, рассматривая альтернативы. С другой стороны, если бы они потеряли кодовую базу, они могли бы восстановить ее, возможно, даже лучше, чем сейчас, но они могли бы получить что-то в сети в очень короткие сроки. Черт возьми, они могли бы купитьчужую клонированную кодовую базу Facebook и загрузите ее с реальными данными, но вы не можете просто скопировать их данные. Если Facebook по-прежнему хранит важные данные всех на своих серверах, стимул уйти гораздо ниже. Все еще плохо, но намного меньше. Удивительно меньше.

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


Краткое изложение длинной ветки комментариев удалено отсюда: «Несправедливо подразумевать, что хранилища NOSQL каким-то образом повышают вероятность того, что вы потеряете данные».
Джек говорит, попробуйте topanswers.xyz

То, что я говорю, связано с возрастом и широким использованием, а не с дизайном механизма хранения.
Даниэль Лайонс

6

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


0

Говоря о nosql, у меня есть только одна вещь, которую нужно добавить о ссылке на Facebook:

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

Выход из дружественного к разработчикам и сверхбыстрого MongoDB, который не может масштабироваться географически, и не имеет возможности эффективно и легко делать резервные копии. Хотя здесь мы используем MongoDB, кажется, Riak или CouchDB выглядят лучше в спецификациях для системных администраторов (у меня нет опыта работы с Riak или CouchDB)


2
Если вы выбираете масштабирование по большому счету, то это потому, что вы уже масштабировали от микро до крошечного, от крошечного до маленького, и по ходу дела вы узнали некоторые вещи, которые помогут вам сделать правильный выбор. Когда вы будете готовы к масштабированию, вы можете позволить себе инженеров, которые знают, как масштабировать.
Jcolebrand
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.