Analyseur SQL pour Wordpress NoSQL Fork

Appelez-moi fou, mais je prévois de Fork wordpress. Je prévois d'échanger MySQL pour Apache Cassandra. Appelez cela ambitieux, mais je prévois de consacrer un peu de temps au cours des prochains mois.Analyseur SQL pour Wordpress NoSQL Fork

En tout cas ma question est: J'essaie de viser à garder les plugins fonctionnels ... En substance tout plugin qui ne nécessite pas leur propre table devrait être en mesure de travailler. C'est le plan, quelqu'un peut-il suggérer une approche pour gérer les requêtes, ce qui me permet effectivement d'analyser les requêtes des plugins.

Seuls les plugins bien, le plan est d'avoir toutes les questions essentielles de base pour les appels supprimés wordpress Cassandra api ...

Source

2010-10-10 zcourts

'Quelqu'un peut-il suggérer une approche pour gérer les requêtes, ce qui me permet effectivement d'analyser les requêtes de plugins.' ... Je ne suis pas un expert dans le fonctionnement interne de WP, et je ne sais pas beaucoup de noSQL, mais wouldn ' T-il une option pour remplacer/réécrire '$ wpdb-> query()' au lieu d'analyser et de remplacer les appels de requête? –

vous pourriez simplement créer une goutte dans le fichier db.php (comme avec ici: http://wordpress.org/support/topic/bug-fix-wpdb-insert-amp-update-with-null-values) qui interprète le questions sur les requêtes cassandra .. je ne sais pas quel avantage réel vous gagnerez si – Ben

@Pekka, je suis toujours "recherche" comment le mieux résoudre si OverRose/écrasement peut être une approche. @Ben, j'y ai pensé aussi mais l'analyse de toutes les requêtes au lieu de seulement celles provenant des plugins peut amener wp à un arrêt presque stable. C'est une idée cependant et je pourrais bien finir par essayer toutes les suggestions que je reçois ici pour voir si l'un d'eux donne quelque chose – zcourts

jusqu'à quel point sont le long-vous à cet effort? Je pense faire la même chose, alors je suis prêt à aider.

Déf. pas une expérience pour nous. Mon équipe doit utiliser wordpress sur beaucoup d'ordinateurs et nous ne nous soucions pas vraiment des plugins cassés, ceux-ci peuvent être corrigés pour implémenter une interface DB quand il s'agit de créer leurs entités, les gains d'une redimensionnement horizontal sans avoir à gérer mysql et les problèmes de configuration sont énormes, pas un seul échec, des temps de réponse plus courts, et vous avez une plate-forme sur laquelle vous pouvez penser à des services plus intéressants sur wordpress. Je trouve ça dingue que l'automatisme ne montre pas vraiment d'intérêt pour l'indépendance de DB, peut-être qu'ils ont un problème avec mysql qui les en empêche, mais eh bien, ce sont des nazis GPL, s'ils ne le sont pas avec nous, alors on peut les fourchonner, je suis sûr que tous les plugins majeurs seront ré-implémentés pour être supportés sur noSQL dbs. http://wordpress.org/support/topic/suggestion-support-mongodb-hypertable-or-other-nosql-storage

Source

2010-11-30 22:48:11 Gubatron

Ive seulement piquer autour du code source. sans l'intérêt de qui que ce soit, j'allais en laisser la plus grande partie jusqu'à l'été prochain, quand j'aurais plus de temps pour le faire moi-même, mais si je reçois de l'aide, je serais prêt à accélérer un moyen. Je suis également très familier avec Apache Cassandra, en écrivant un livre sur le fait. Donc, si vous êtes une équipe n'a pas de liens avec mongodb alors encore mieux. Bien que je devrais être capable d'apprendre facilement les ons et outs de mongodb. S'il vous plaît laissez-moi savoir si cela peut continuer, je serais très intéressé à en faire partie. – zcourts

Juste pour ajouter à ce que j'ai trouvé au hasard ce sujet, il y a ce projet:

http://www.mongopress.org/

Je suis aussi très intéressé par ce domaine que mes problèmes avec mise à l'échelle WordPress viennent toujours MySQL

Source

2012-04-21 11:10:08

Il semble qu'après quelques jours de codage, je viens de recevoir quelque chose qui pourrait être à peu près "preuve de concept" pour migrer Wordpress de MySQL à NoSQL (disons Mongo). Je pense que la même approche pourrait être utilisée aussi plus en général (traducteur SQL vers NoSQL).

L'idée est de préparer des mappages déclaratifs supplémentaires "tables to collections". Utilisez ensuite ces mappages pour traiter les insertions MySQL/SQL dans les mises à jour NoSQL/Mongo. Pour aller plus loin - les mêmes correspondances peuvent être utilisées pour traduire aussi les suppressions et les sélections (les jointures peuvent aussi être gérées en utilisant du cache auxiliaire stocké dans nosql en tant que document).

L'effet devrait être Wordpress sur SQL sans changement significatif (en dehors de l'ajout d'une petite couche de traducteur SQL). La surcharge de performances peut être réduite en créant un cache SQL supplémentaire qui simplifiera l'analyse SQL.

quelque chose de similaire trouvé ici:

http://databasesincloud.wordpress.com/2011/05/25/talking-sql-to-nosql-data-stores-part-2/

Toute personne intéressée?

Source

2013-02-10 21:18:29 Virtimus

Répondre

Questions connexes