J'ai une question de simpleston sur Redis. Si la clé de sa performance est que c'est en mémoire, WHEY ne peut pas être effectué sur un DB SQL normal?
6 Réponses :
Tout SGBD peut être exécuté "en mémoire". Considérez l'utilisation d'un Ramdisk . Cependant, la plupart des DBMS (ceux avec SQL) sont non conçus à exécuter entièrement en mémoire et de mettre beaucoup d'effort pour minimiser le disque IO et la pagination: un DBMS fonctionne très difficile à conserver Les "données pertinentes" chaud (en mémoire et en cache) - io est lente, lente lente.
En effet, les données de base de données sont souvent [et ont toujours été] significativement plus grand que la mémoire principale. Cette mémoire principale est volatile :-) [Les DBMS acides font beaucoup d'œuvres avec une journalisation en écriture à l'avance - à un magasin non volatile - et d'autres techniques pour que les données ne soient jamais corrompues, même en cas d'arrêt inattendu. ]
Certaines bases de données, telles que SQLite, utilisez le même format pour les magasins de disque et de mémoire même s'ils prennent explicitement en charge un magasin en mémoire. Prise en charge des autres back-extrémités [en mémoire] et le réglage d'utilisation de la mémoire varie selon le fournisseur.
codage heureux.
La clé n'est pas seulement en mémoire, mais elle a également des opérations plus simples qu'un DB SQL. Redis a des opérations simples telles que Get, Set (etc.) à l'aide de tables de hachage et d'autres structures de données optimisées.
Les bases de données SQL prennent généralement plus de temps pour calculer, mais elles sont une tonne plus flexible et dans la plupart des cas plus puissants (en termes de quel type de requêtes). Vous ne pouvez certainement pas exécuter les requêtes de Redis, par exemple
Désolé, on a dit à d'autres développeurs que dans la mémoire était la clé et de ce wiki (sous-section: performance)> EN.WIKIPEDIA.ORG/WIKI/REDIS_%28DATA_STORE%29
Vous pouvez le faire de manière native avec certains systèmes de gestion de la base de données SQL. Mais il y a des risques.
Vous devez perdre des données si le serveur échoue, par exemple. Je ne pense pas que vous puissiez obtenir des transactions conformes aux acides; Tout fichier journal devrait être écrit sur le disque pour survivre à une défaillance du serveur. (J'imagine qu'il est possible pour un SQL SQL en mémoire d'écrire des fichiers journaux sur le disque, mais je ne traverse jamais cela moi-même. Pas que j'ai regardé beaucoup.)
Que diriez-vous de la mémoire flash alors? Soi-disant, la loi de Moore est plus rapide que l'activité transactionnelle humaine de sorte que la différence de vitesse du mouvement des octets électroniques est réduite.
Les lecteurs d'état solide (SSD) sont relativement coûteux. Aujourd'hui, une SSD de 256 Go de crucial est de près de 200 $. Un disque dur du caviar de 2 téraabyte WD est inférieur à 90 $. Je pense que vous auriez besoin d'une ingénierie supplémentaire pour garantir des données survives - un disque dur généralement se dégrade avant l'échec, mais un SSD meurt généralement une mort flamboyante. Votre SGBD aurait besoin de gérer gracieusement la destruction totale du lecteur.
Vous pouvez être intéressé par in horodatage < / a> (qui est maintenant oracle ).
11g son SQL s'est considérablement amélioré, mais n'est toujours pas aussi puissant que celui de oracle .
Quand ce jour arrive ce sera génial, mais j'ai besoin de pétaoctes et au-delà aujourd'hui.
Croyez-vous que l'avantage de la performance de NOSQL sera suffisamment diminué puis de perdre la plupart des appels?