Quelle base pour stocker 100 million de ligne ? – part 2 : Mysql vs PostgreSql

Étude technique Comment choisir la base de donnée Dans notre besoin, une base de donnée clés / valeur correspondrait à notre attente car nous aurions besoin d’une clé (id de la base alfresco) et d’une valeur (les métas du document). En soi, une base de donnée relationnelle peut tout à fait faire le job : une colonne ‘alfrescoID’ indexée et une colonne ‘metadata’. Les dernières versions de bases relationnelles permettent d’avoir des colonnes de type json et donc introduisent le paradigme ‘document storage’ puisqu’il devient possible de requêter du json. Avant de choisir le paradigme de la base de données dont nous avons besoin (relationnelle / clés/valeur / document / graph), il est important de savoir ou l’on doit se situer sur le théorème de CAP. Si nous n’avons pas besoin de partitionnement, une base relationnelle suffirait. Comment savoir si une base relationnelle a besoin de partitionnement ? La réponse est simple : Si les indexes ne tiennent pas en RAM, les performances sont dégradés et on a besoin de les partitionner. A partir du moment où il y a besoin de partitionnement, il vaut mieux quitter les bases SQL conventionnelles pour aller vers les bases NOSQL. Condition du benchmark Pour le benchmark, nous allons comparer 2 bases relationnelles : mysql 5.8 (dernière version) et postgre 10.3 (dernière version). Je vais générer 100 000 lignes, avec une colonne ‘dbid’ qui correspond a l’id dans la base alfresco et une colonne ‘data’ qui contiendra un json ~2MO. L’idée est de vérifier l’empreinte mémoire utilisée par la base pour stocker les dbid/métadonnée d’un document. Si l’empreinte mémoire est trop grande, il faudra songer à utiliser des bases NoSQL. Les tests seront effectués sur un serveur avec les caractéristiques suivantes : OS : windows server 2012 à jour RAM : 64Go Proc : 4 proc a 2.39GhZ SSD 1To C’est parti ! Étape 1 : installation Installer un serveur postgresql 10 à été très facile, double clique sur l’exe, suivant -> suivant et tout fonctionne très bien. Pour installer le serveur MySql c’est beaucoup plus laborieux, il faut installer toutes les dépendances .net Étape 2 : Mesure de l’empreinte mémoire à vide Je profite de ce chapitre pour dire qu’il est très difficile de mesurer l’empreinte mémoire utilisée par un service sous Windows. Je m’y suis pris de trois manières différentes, mais aucune ne retourne le même résultat. Nous allons en étudier...

Read More

Quelle base pour stocker 100 million de ligne ? – part 1 : théorie

Expression du besoin fonctionnel L’objectif est d’être capable de stocker 100 000 000 documents avec alfresco. On sait déjà que la base de donnée alfresco ne tiendra jamais la charge. Le but est donc de déléguer le stockage des méta-données à une base externe (laquelle ?) afin de décharger la base alfresco. Il y a aussi un moteur d’indexation (solr) qui indexe tous les documents et qui effectue la recherche sur les méta-données. Ainsi le rôle de la base de donnée est de stoker la donnée et pas d’effectuer des recherches. Une requête Solr renverra des ID de base de donnée mysql correspondant à cette recherche. Pour soulager la base alfresco, il faudrait une seconde base de donnée qui fasse le mapping entre l’id de la base alfresco et les méta-donnée du document. Théorie sur les bases de données Théorème de CAP Dans ce chapitre, nous allons faire un peu de théorie et étudier le théorème de CAP. Consistency C = Consistence = La donnée est fiable. Après un insert ou un update, quand on fait un read, on est certain que la donnée soit à jour. Availability A = Availability = Le fait que la base de donnée soit rapide à répondre (haute vitesse d’accès à la donnée). Partitioning P = Partitioning = Quand on a des grosses base de données, un seul serveur ne suffit plus pour tout stocker, il faut partitionner la donnée sur plusieurs serveurs. Le théorème de CAP dit qu’il est possible d’avoir seulement 2 de ses trois choses. Les bases de données relationnelles (postgresql, mysql) sont des bases de données CA (la donnée est rapide d’accès et toujours fiable) mais se scale très mal. Le partitioning n’est pas impossible, mais l’overhead de partitioning coute très cher. A partir du moment il faut commencer à avoir un cluster, il faut songer à des bases de données AP ou CP. Par exemple, mongoDB est une base de donnée CP : Elle est capable d’être clusterisée sans payer de gros overhead, et la donnée est toujours consistante. Après un update, la donnée est tout de suite mise à jour sur tous les clusters. Le coût a payer pour cela est une vitesse de lecture diminuée (availability). D’un autre côté, il y a Cassandra : une basse de donnée AP. C’est à dire que Cassandra se clusterise très bien tout en gardant des vitesses d’accès comparables à...

Read More

Import Oracle database dump

Hello, Today we will see how to import oracle dumped database. Create a tablespace with 2Go memory Shell CREATE TABLESPACE <tablespace name> DATAFILE 'cecm.dbf' SIZE 2048M ONLINE; 1 CREATE TABLESPACE <tablespace name> DATAFILE 'cecm.dbf' SIZE 2048M     ONLINE; 2. Create <user> Shell CREATE USER <username> IDENTIFIED BY <password>; 1 CREATE USER <username> IDENTIFIED BY <password>; 3. give him dba access : Shell GRANT dba TO <username> WITH ADMIN OPTION; 1 GRANT dba TO <username> WITH ADMIN OPTION; 4. copy dump into the dump directory : Shell mv oracle_dump.DMP /u01/app/oracle/admin/XE/dpdump/ 1 mv oracle_dump.DMP /u01/app/oracle/admin/XE/dpdump/ 5. Finally, launch the dump : Shell impdp <username>/<password> dumpfile=oracle_dump.DMP logfile=out.log full=y; 1 impdp <username>/<password> dumpfile=oracle_dump.DMP logfile=out.log full=y;      ...

Read More

Oracle – Supprimer une contrainte et ces index

Bonjour à tous,   récemment au travail j’ai rencontré des problèmes dû au fait qu’en supprimant une contrainte sur une table oracle, les index n’était pas correctement supprimé.   Voici un exemple de requete qui supprime une constrainte et ces index :   Oracle PL/SQL alter table ACT_RE_PROCDEF drop constraint ACT_UNIQ_PROCDEF; DECLARE COUNT_INDEXES INTEGER; BEGIN SELECT COUNT(*) INTO COUNT_INDEXES FROM USER_INDEXES WHERE INDEX_NAME = 'ACT_UNIQ_PROCDEF'; IF COUNT_INDEXES > 0 THEN EXECUTE IMMEDIATE 'DROP INDEX ACT_UNIQ_PROCDEF'; END IF; END; alter table ACT_RE_PROCDEF add constraint ACT_UNIQ_PROCDEF unique (KEY_,VERSION_, TENANT_ID_); 1234567891011121314151617 alter table ACT_RE_PROCDEF drop constraint ACT_UNIQ_PROCDEF; DECLARE  COUNT_INDEXES INTEGER;BEGIN  SELECT COUNT(*) INTO COUNT_INDEXES    FROM USER_INDEXES    WHERE INDEX_NAME = 'ACT_UNIQ_PROCDEF';   IF COUNT_INDEXES > 0 THEN    EXECUTE IMMEDIATE 'DROP INDEX ACT_UNIQ_PROCDEF';  END IF;END; alter table ACT_RE_PROCDEF    add constraint ACT_UNIQ_PROCDEF    unique (KEY_,VERSION_, TENANT_ID_);  ...

Read More