Quelle est la configuration matérielle minimale requise pour un cluster PostgreSQL avec Rails frontend, avec beaucoup de petites écritures et de longues lectures ?

Question

Le contexte :

J'essaie de déterminer les exigences minimales pour une application que je suis en train de créer. Je maîtrise assez bien MySQL et PostgreSQL pour un développeur, mais je ne suis pas un DBA, d'où ma question. Je suis en train de créer une application mobile, qui communiquera avec une API distante, et j'ai besoin de déterminer les exigences pour cette API. À ce stade, il s'agit d'un projet de loisir et l'application mobile sera gratuite, donc je n'ai pas un gros budget - et j'ai besoin de déterminer mes exigences aussi précisément que possible.

Conditions de candidature :

L'API distante est réalisée en Rails et fournit des interfaces web et json, qui stockent les données dans un cluster postgresql. L'application mobile enverra beaucoup de courtes écritures ~ environ 1 par minute * 20.000 installations d'applications. La plupart des lectures seront des rapports, donc des lectures plus longues, qui ne se produisent pas si souvent - peut-être une ou deux fois par jour par utilisateur. La base de données doit donc être optimisée pour les écritures. Les actions de lecture peuvent toujours être redirigées vers un cluster/serveur réplique, car à ce stade, elles n'ont pas besoin d'être en temps réel. Un délai d'un jour est suffisant.

Plus de détails par question dans les commentaires :

1) Les écritures sont très petites : je vais renvoyer une sorte de jeton d'authentification (comme une clé api) et très peu de données - nous parlons de moins de 1kb de données : horodatage, et coordonnées GPS, peut-être quelque chose d'autre éventuellement, mais j'en doute. Je n'envisage pas de grosses données comme des photos ou autre chose du genre. Ce sera similaire à une application de suivi de course à pied / jogging / vélo.

2) Mise à l'échelle ? Hmm. 200 000 à 400 000 applications maximum si le projet décolle vraiment au cours des deux premières années.

3) Les données sont assez critiques. L'objectif est de pouvoir produire des rapports précis une fois les données collectées. Il existe cependant deux options pour atténuer ce problème :

• Je peux l'estimer en me basant sur les données de Google maps et les derniers points connus ( juste avant la perte de données, et juste après le rétablissement de la connexion).
• Les données sont d'abord enregistrées sur le téléphone dans un stockage sqlite et une fois par jour (ou au démarrage de l'application) elles sont synchronisées avec le serveur / vérifiées. Une fois que la vérification / synchronisation est réussie, les données sur le téléphone peuvent être tournées (comme tout ce qui est plus vieux qu'un mois peut être effacé du téléphone).

Détails de la question réelle

Ma question s'adresse donc à quelqu'un qui s'est occupé d'applications à cette échelle. Quelle était votre configuration initiale de PostgreSQL, tant au niveau de la configuration du cluster que du matériel (cloud), et dans quelle mesure était-il facile ou difficile de la faire évoluer ?

---

POUR éviter les suggestions et les réponses non pertinentes :

Alternatives NoSQL

J'ai envisagé des alternatives NoSQL comme CouchDB, MongoDB, etc . Riak est en fait sorti vainqueur, étant donné qu'il est facile à gérer pour une équipe d'un seul homme et que je n'ai besoin que de 3 serveurs de données pour avoir un cluster de réplication fonctionnel. Mais après avoir dressé la carte de mon application, je me suis dit que NoSQL n'était pas une bonne solution pour cette application, et qu'elle appartenait au domaine des SGBDR.

Alternatives NoSQL et options SQL

Compte tenu de mon budget inexistant, je n'ai même pas envisagé le serveur SQL, Oracle et autres. MySQL est la seule autre alternative réelle, mais j'ai besoin de hstore, et la réplication est plus facile à mettre en œuvre actuellement dans PostgreSQL IMHO.

Answer 1

C'est une bonne nouvelle :

Les données sont d'abord enregistrées sur le téléphone dans un stockage sqlite...

Ainsi, nous n'avons pas à faire face à des rafales de petites écritures, nous pouvons regrouper les mises à jour. De plus, nous pouvons les rejeter occasionnellement et l'application peut réessayer plus tard. Autre avantage, nous pouvons probablement louer au mois plutôt qu'à l'heure (moins cher !).

Cela signifie que notre limite est purement due au maximum d'E/S de disque durable. Vous mentionnez maintenant "le nuage", ce qui complique les choses. Les E/S sur disque bon marché sont généralement médiocres pour les bases de données (quel que soit leur type) et les bons éléments sont chers.

Quelques calculs à l'arrière de l'enveloppe...

20 000 applications @ 1kB / min ~ 20 MB/min ~ 333 kB/sec 200 000 applications à 1 ko / min ~ 200 Mo/min ~ 3,3 Mo/s

Vous écrirez d'abord dans le journal des transactions (WAL), puis dans les tables, et vous devrez tenir compte de vos rapports, mais ce n'est pas grand-chose. Si vos besoins en matière de disque augmentent considérablement, vous feriez mieux de vous doter d'un couple de machines gérées, réelles, avec leurs propres disques.

Donc - script vous-même une configuration de serveur PostgreSQL. Je trouve ansible est assez facile à mettre en œuvre. Ajoutez quelques scripts de test pour simuler différents nombres de requêtes et tailles de lots. Vous devriez être en mesure de lancer une machine virtuelle, d'exécuter un lot de tests et d'obtenir des chiffres réels en quelques heures par fournisseur.