Пропозиція в базі даних для спільноти соціальної мережі / бази знань?

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

Я створив системи в MySQL та postgreSQL, тепер я хочу розширити свої знання та досвід роботи з базами даних.

Мій проект буде типом соціальної мережі / сукупним знанням. (досі не розробив термін для його опису).

Я дивився на:

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

Вимоги системи:

• Текст даних , дати, час, xml, маленькі вставки, краплі,
• Структура / поведінка : нормалізований 3NF , не в режимі реального часу, реляційний, масштабований, надійний
• Навколишнє середовище: unix / linux, без JAVA !, бажано працювати на C

Мені було цікаво, чи можете ви вказати мені на будь-які інші системи баз даних, які я повинен дослідити.

Я також ознайомився з об'єктно-реляційними базами даних, мені дуже подобається ідея, що вони працюють з PHP-об'єктами (PDO), однак їх ефективність здається трохи поганою.

Зважаючи на те, що тут буде DBA, будь-які відгуки про ці системи, якими ви працювали, будуть вдячні.

Дякую

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

Безкоштовні речі

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

Дивні безкоштовні речі

• Metakit - більше вбудована база даних на зразок SQLite, але не заснована на SQL, тому більш процедурна.
• FramerD - дуже схожа на класичну "мережеву" базу даних, дуже орієнтована на вказівник. Можливо, мертвим?
• Magma - Smalltalk OODBMS. Класно, але не добре задокументовано.

Невільні речі

• AllegroGraph - база даних RDF (graph), підтримує SPARQL. Ароматизований смак.
• Caché - гібридна реляційна база даних / OO, спочатку заснована на MUMPS (IIRC).
• Об'єктивність - Одне з останніх дійсно великих OODB. Дуже потужний, вражаючий і дорогий.
• VoltDB - Масштабована здебільшого реляційна база даних. Підтримує "більшість" SQL. Зовсім нове. Я думаю, вони також мають версію для спільноти.

Висновок

Я не використовував жодної з цих речей широко. Я трохи пограв з більшістю з них і завжди заводився з PostgreSQL. З огляду на ваші вимоги, єдиний PostgreSQL не відповідає поза коробкою - це масштабованість. З іншого боку, для моїх цілей набагато простіше кинути 4000 апаратних засобів на одну спеціалізовану машину баз даних, ніж викинути 4000 доларів хмарних вузлів або низькопробних машин на цю проблему. І є способи досягнення масштабованості за допомогою PostgreSQL, наприклад, з EnterpriseDB .

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

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

Розглянемо це. Уявіть, що ви - Марк Цукерберг, і вам доведеться вибрати або відмовитись від кодової бази чи своїх даних. Ви можете зберегти весь свій персонал з розробки, але вам доведеться відмовитися від усього коду - кожен рядок, скажіть, навіть усі спогади розробників про те, як вони реалізували все, пропало - але ви маєте зберегти всі свої облікові записи користувачів і всі ваші користувачі завантажені даних і всього цього, або ви можете відмовитись від усіх даних. Зберігайте всі структури та сервери та конфігурацію, налаштування, але втрачайте кожен рядок у кожній таблиці кожної бази даних.

Має бути очевидним, що було б гірше втратити дані. Чому б усі ваші користувачі відновлювали всі ці дані? Подумайте про всі втрачені маркетингові дані, саме так Facebook фактично заробляє свої гроші. І є багато підприємців, які сльозяться на можливість змусити людей користуватися своїм клоном у Facebook - тепер усі ті, хто не має права, колишні користувачі Facebook будуть там, розглядаючи альтернативи. З іншого боку, якщо вони втратили кодову базу, вони могли б її відновити, можливо, навіть краще, ніж зараз, але вони могли б мати щось в Інтернеті за дуже короткий час. Чорт забирай - вони, ймовірно, могли купитихтось інший Facebook клонує кодову базу даних і завантажує їх реальними даними, але ви не можете просто скопіювати їх дані. Якщо у Facebook все ще є важливі дані для кожного на своїх серверах, стимул до відходу значно нижчий. Ще погано, але набагато менше. Дивно менше.

Іронія полягає в тому, що набагато простіше втратити всі свої дані у вигаданій аварії, ніж втратити весь код. Для більшості інтернет - компаній, однак, дані є компанією, вона є найбільш цінним активом. І це вагомий привід розглянути можливість використання традиційної, перевіреної часом, старомодної, несексуальної реляційної бази даних.

Враховуйте також, що немає жодної причини, чому ви не можете використовувати реляційну базу даних для деяких речей, а базу даних nosql - для інших.

Говорячи про nosql, у мене просто є що додати про посилання на Facebook:

Якщо ви плануєте масштабувати дуже великі, я пропоную вам отримати двигун БД, що відповідає сидадміну, порівняно з розробником.

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