Bonjour je crée une sorte d'annuaire et pour le moment j'expérimente en local:
Wamp 2.5 64 bits livré avec MySQL
 
Je développe sous python et il y a une lib bien pratique pour MySQL
 
MAIS (il y a toujours un mais...)
J'ai des tables qui contiennent plusieurs millions d'entrées et ça commence à pédaler (en local alors imaginez une fois le projet lâché sur le net)
 
=> QUESTION
CASSANDRA semble être la réponse à mon problème mais comment coder des requêtes ?
Il semble que le SGBDD soit complètement différent (adieu les INSERT IGNORE INTO WHERE FROM SELECT COUNT etc etc ???)
 
Merci de m'éclairer

En plus, faudra que tu revois toute l'architecture, voir http://ippon.developpez.com/tutori [...] cassandra/  
 
Mais avant de te réorienter là-dessus, ce qui va te demander énormément de modifications à faire, tu devrais à mon avis :
- Essayer d'optimiser tes requêtes
- Essayer d'optimiser tes tables
- Déterminer quelles requêtes select prennent le plus de temps, et éventuellement voir pour remodéliser tes tables en fonction de ça.
 
Car mysql peut sans problèmes gérer des millions d'entrées.

Cassandra n'a pas de problème d'optimisation de requête parce que seules les formes les plus simples des SELECT, INSERT, UPDATE, DELETE sont possibles. En gros, dans les WHERE on a généralement droit à : key = ?, et optionnellement à uneColonneConstituantLaPrimaryKeyEtRienDautre = ? et c'est tout.
La question à se poser avec Cassandra n'est donc pas comment coder les requêtes mais quelles données doit-on entreposer pour l'usage que l'on veut en faire ?
 
Si les données que l'on veut récupérer ne peuvent pas être pré-entreposés alors Cassandra n'est pas adapté à ce besoin. (requête multi-critères, full text) On utilisera plutôt du Solr ou du MySQL suivant les cas.
 
Dans tous les cas, on peut faire du NoSQL avec MySQL, la différence avec une base de données Cassandra se fera surtout sentir dans un contexte de base de données distribuée sur plusieurs serveurs, et une concurrence de requêtes avec un certain ratio write/read.
 
Comme le problème ici est plutôt un accès mono-user qui en quelques select fait pédaler MySQL, il faudrait plutôt commencer à :
- optimiser les requêtes avec EXPLAIN sur MySQL
- mettre en cache les résultats des requêtes coûteuses qui sont déjà optimisées dans un serveur de cache comme memcached

merci à bistouille et à CZH
Pour donner une idée, je suis sur un moteur de recherche d'images et j'ai environ 9 tables liées. pour le moment j'ai, en une semaine:
150 000 images scannées répertoriées et indexées mais ça s'accélère, je devrais passer la barre des 500 000 en une semaine
chaque image a des caracteristiques, du texte, des dimensions, des dates de scan, chaque site a des enregistrements de dates pour "rescanner" (genre infos piquées dans les sitmap.xml)
je dois avoir environ 1 500 000 adresses à scanner pour le moment, ce qui potentiellement peut me retourner 5 fois plus d'images et donc:
15 millions d'images
15 millions d'infos diverses
15 millions de descriptions
etc etc
le tout dans diverses tables, et en deux semaines, sauf si je double le nombre de robots...
 
MERCI