Quelle est la base de données non sql la plus rapide et la plus stable pour stocker de grandes données et traiter des milliers de demandes pendant la journée (c'est pour le service de change)? J'ai trouvé KDB + et Berkeley DB. Sont-ils bons? Y a-t-il d'autres options?
Plus de détails ...
Chaque jour Server Processes> Visites 100k. Pour chaque visite, j'ai besoin de lire des statistiques correspondantes à partir de DB, d'écrire un journal des statistiques de DB et de mise à jour de DB, alias 3 opérations avec DB par visite. Le trafic augmente continuellement. Ainsi, DB Moteur devrait être rapide. D'un côté DB sera géré par Demon écrit sur C, Erlang ou toute autre langue de bas niveau. D'un autre côté DB sera géré par des scripts PHP.
6 Réponses :
Le système de fichiers lui-même est plus rapide et plus stable que presque autre chose. Il stocke de grandes données de manière transparente et efficace. L'API est très simple.
Vous pouvez stocker et récupérer du système de fichiers très efficacement.
Étant donné que votre question est un peu mince sur "exigences", il est difficile de dire beaucoup plus.
Quel est le problème avec SQLLITE ? Puisque vous avez explicitement indiqué non-SQL, Berkeley DB est basé sur des paires de clés / de valeur qui pourraient ne pas suffire à vos besoins si vous souhaitez élargir les jeux de données, en plus, comment allez-vous que l'ensemble de données se rapporte à la clé / Valeur paires ....
D'autre part, KDB +, en regardant le FAQ sur leur site Web est un rapport relationnel Base de données capable de gérer SQL via leur langage de programmation Q ... Sachez que si la nécessité de migrer apparaît, il pourrait y avoir des attelages potentiels, tels que des dialectes incompatibles ou une requête qui utilise des spécificités du fournisseur, d'où le potentiel pour être verrouillé dans cette base de données. Et ne pas être capable de migrer du tout ... quelque chose à garder à l'esprit pour plus tard ...
Vous devez faire attention à ce que vous décidez ici et la considère comme une perspective à long terme, des mises à niveau futures, une migration vers une autre base de données, quelle serait sa capacité à augmenter à échelle, etc.
Vous feriez des données de données se rapportant les unes aux autres en stockant plus d'un scalaire simple dans le champ Valeur. Berkely ne se soucie pas de ce que vous stockez, il le traite comme une blob d'octets.
Une entrée évidente dans cette catégorie est l'intersystème Caché. (Bien, évident pour moi ...) Soyez au courant, cependant, ce n'est pas bon marché. (Mais je ne pense pas que kdb + est non plus.)
Qu'en est-il de Redis?
http://code.google.com/p/redis/
N'essayez pas encore de l'avoir lu et il semblerait être un assez rapide et suffisamment stable pour le stockage de données. Il vous fournit également une solution décente d'échec anti-point à point unique, autant que je sache.
Berkely dB est essayé et testé et durci et est au cœur de nombreux systèmes de volume de transaction méga-élevé. Un exemple est une infrastructure de transporteur sans fil utilisant d'énormes magasins LDAP (OpenWave, par exemple) pour traiter plus de 2 milliards de transactions par jour. Ces systèmes ont également couramment quelque chose comme Oracle dans le mélange aussi pour le point de récupération de temps, mais ils utilisent Berkeley DB comme caches répliquées.
En outre, BDB ne se limite pas aux paires de valeurs clés dans le sens simple des valeurs scalaires. Vous pouvez stocker tout ce que vous voulez dans la valeur, y compris les structures / enregistrements arbitraires.
MongoDB est la base de données NOSQL la plus rapide et la meilleure. Regardez sur Ce benchmark de performance .
"Sont-ils bons?" Berkley DB existe depuis des décennies. Que devez-vous savoir de plus? "Y a-t-il d'autres options"? Toujours. Mais, puisque vous ne fournissez pas beaucoup d'antécédents ou de conseils, il est difficile de faire une suggestion concrète.
Lorsque vous vous référez à la base de données non-SQL. Êtes-vous préoccupé par un moteur SQL "basé sur un service"? vs une DLL de dépose, telle que d'autres mentionnées sur SQLite (ainsi que Sybase Advantage Server local). Pour les demandes contre «trafic», vous décrivez des données «grosses», et c'est également tout relatif sur la normalisation des données.
Des milliers de demandes par jour? Sérieusement, les gens utilisent des bases de données SQL pour servir des milliers de demandes par seconde et avec des requêtes complexes à cela. Cette odeur d'optimisation prématurée.