База данных, основанная на Heroku

Question

В какой-то момент в ближайшие несколько месяцев наше приложение будет иметь размер, где нам нужно очертить нашу БД. Мы используем Heroku для хостинга, стек Node.js/PostgreSQL.

Концептуально для нашего приложения имеет смысл, чтобы каждый логический очерк представлял одного пользователя и все данные, связанные с этим пользователем (каждый пользователь нашего приложения генерирует много данных, и между пользователями нет взаимодействия). Нам нужно сохранить возможность для пользователя выполнять сложные специальные запросы по своим данным. Я прочитал много статей, таких как этот, который говорит о шрамах: http://www.craigkerstiens.com/2012/11/30/sharding-your-database/

Концептуально я понимаю, как работает Шардинг. Однако на практике я понятия не имею, как это реализовать на Heroku, с точки зрения того, какой код мне нужно написать, и какие части моего приложения мне нужно изменить. Было бы очень полезно оценить ссылку на учебник или некоторые указатели.

Вот некоторые ресурсы, я уже посмотрел на:

• http://www.craigkerstiens.com/2012/11/30/sharding-your-database/
• MySQL sharding approaches?
• Heroku takes care of multiple database servers?
• http://petrohi.me/post/30848036722/scaling-out-postgres-partitioning
• http://adam.heroku.com/past/2009/7/6/sql_databases_dont_scale/
• https://devcenter.heroku.com/articles/heroku-postgres-follower-databases
• Why do people use Heroku when AWS is present? What distinguishes Heroku from AWS?

Answer 1

Я не уверен, что назову это «осколки».

В LedgerSMB вот как мы поступаем. Каждая компания (бизнес-единица) представляет собой отдельную базу данных с полностью раздельными данными. Данные не могут быть распределены между компаниями. Один кластер postgreSQL может запускать любое количество баз данных компании. У нас есть административный интерфейс, который создает базу данных и загружает схему. Административный интерфейс также может создавать новых пользователей, которые могут совместно использоваться компаниями (необязательно). Я не знаю, насколько хорошо это работает, чтобы делиться пользователями между dbs на Heroku, но я включаю эту деталь с точки зрения того, как мы работаем с PostgreSQL.

Так что это жизнеспособный подход.

Что вам действительно нужно, это то, что можно развернуть базы данных и управлять пользователями автоматическим способом. Оттуда вы можете потребовать, чтобы пользователь указывал название компании, которое можно сопоставить с базой данных, но вы хотите (это сопоставление может быть сохранено в другой базе данных, например).

Я знаю, что это довольно высокий уровень. Однако вы должны начать работать.

Answer 2

Как автор первой статьи счастлив перезвонить в дальнейшем. Когда дело доходит до осколки, одним из ключевых компонентов является то, к чему вы клоните. Сложность ошпаривания действительно вступает в игру, когда у вас есть данные, которые перемежаются между различными физическими узлами. Если вы что-то вроде приложения с несколькими арендаторами, то моделируете все свои данные вокруг этой идеи арендатора или клиента can fit very cleanly in this setup. В этом случае вам захочется разбить все таблицы, связанные с клиентом, и очертить их так же, как и другие таблицы, связанные с арендатором.

Что касается этого на Героку, существует два варианта. Вы можете сворачивать с помощью Heroku Postgres и логики приложений или использовать что-то вроде Citus (которое является дополнением, которое помогает справиться с этим больше для вас.

Для того, чтобы сворачивать самостоятельно, вы сначала создадите различную логику приложения, чтобы обрабатывать все ваши осколки и знать, куда направлять соответствующие запросы. Для Rails есть некоторые драгоценные камни, чтобы помочь с этим, например, activerecord-multi-tenant или apartment. Когда дело доходит до того, что вы перейдете к очертаниям и этой миграции, то, что вы хотите сделать, это создать последователя Героку, чтобы начать. Во время миграции вы начнете ее отменять. Затем вы удалите половину данных из исходной первичной и другой половины от последователя, которого вы разделили соответственно.