Dans une autre session qui s'est tenue lors de la conférence NoSQL Now, le consultant Dan McCreary a expliqué que les lacunes présentes dans les bases de données relationnelles ont stimulé le travail des développeurs afin de créer des systèmes NoSQL. Les bases traditionnelles ne sont pas très flexibles, a-t-il dit. Leur architecture de base a été conçue à l'époque des cartes perforées, et reflète une approche rigide dans la modélisation des données. Si un utilisateur a besoin d'ajouter une autre colonne de données, il doit modifier le schéma de base ce qui peut être très délicat à faire. Le processus de modélisation pour créer des tables relationnelles, appelées modélisation entité-relation, ne reflète pas toujours exactement la façon dont les données existent dans le monde réel. « Beaucoup de choses ne rentrent pas bien dans les tables », a-t-il dit. « C'est beaucoup trop restrictif. » 

Un des autres problèmes avec les bases de données SQL, c'est qu'elles ne s'adaptent pas très bien à la répartition de la charge de travail sur plusieurs serveurs, souligne Dan McCreary. Si les données se développent au-delà des capacités de traitement d'un seul serveur, la base doit être fragmentée, ou dispersée, sur plusieurs serveurs, ce qui est également un processus compliqué. En outre, l'exécution de certaines opérations sur plusieurs serveurs, telles que les requêtes sur plusieurs tables, dans lesquelles les données ont été dispersées, peut devenir problématique.

Les limites du NoSQL

Alors que les bases de données NoSQL offrent plus d'évolutivité et plus de flexibilité, elles ont également leurs propres limites, souligne Michael Stonebraker. En n'utilisant pas SQL, les systèmes de base de données NoSQL perdent la capacité de faire des requêtes très structurées avec une certitude mathématique. Reposant sur l'algèbre et le calcul relationnel, SQL propose un modèle mathématique assurant que la requête est structurée de telle sorte qu'elle ramène toutes les données à capturer, même si la requête elle-même est très complexe. 

Autres problèmes: NoSQL ne peut pas fournir d'opérations au niveau ACID (Atomicity, Consistency, Isolation and Durability) un ensemble de métriques largement utilisées pour assurer qu'une base de données réalisant des transactions en ligne restera toujours précise même si le système est interrompu. Assurer la conformité ACID peut être gravé dans les couches basses de l'application, même si l'écriture du code nécessaire à ces opérations « est un travail pire que la mort », a-t-il ajouté. Enfin, chaque base de données NoSQL vient avec son propre langage de requête, rendant difficile la standardisation des interfaces entre les applications. 

En revanche, NewSQL peut fournir la qualité et l'assurance des systèmes SQL, tout en apportant l'évolutivité des systèmes NoSQL, fait valoir le directeur technique de VoltDB. L'approche NewSQL implique l'utilisation d'un certain nombre de nouveaux modèles d'architecture, a-t-il noté. Il élimine par exemple le pool de mémoire tampon qui monopolise excessivement les ressources en exécutant entièrement  la base de données dans la mémoire principale. Il supprime la nécessité du verrouillage en exécutant qu'une seule thread sur le serveur (bien que certains processus puissent être exécutés pour d'autres opérations bloquées). Et les gourmandes opérations de récupération peuvent être éliminées grâce à l'utilisation de serveurs supplémentaires pour réaliser la réplication et la bascule.