Structure de données pour stocker des tables de base de données arbitraires

Question

Je souhaite concevoir une structure de données JVM (Java/Scala) pouvant être utilisée pour représenter et stocker le contenu de tables de bases de données relationnelles arbitraires. La structure des données doit être rapide (pas trop gourmande en ressources, compatible avec le cache) et efficace en termes de mémoire, afin que les plus grandes tables puissent entrer dans la RAM. Une solution efficace en mémoire consiste à stocker chaque colonne séparément dans un tableau primitif, mais je suis préoccupé par la convivialité de la mémoire cache car les éléments d'une même ligne ne sont pas stockés ensemble. Une rangée avec N colonnes entraînera N échecs de cache, peu importe la taille des colonnes. Une autre solution consiste à stocker chaque ligne dans un tableau d'objets où chaque élément représente un champ et est transtypé au type correct lors de la récupération, mais cela nécessite de stocker des types numériques sous forme de boîte, donc pas très efficace en mémoire. Et ce n'est probablement pas ce cache efficace non plus.

Une autre solution consiste à disposer les données de chaque ligne dans un tableau d'octets de la même manière que les bases de données réelles sérialisent leurs lignes, en utilisant seulement autant d'octets que nécessaire. Ceci est facile à mettre en cache et efficace en termes de mémoire, mais je suis préoccupé par le coût de la sérialisation/désérialisation à chaque accès.

Quelle est la meilleure façon?

Answer 1

Quel est le but de faire cela? Il vaut sans doute mieux stocker simplement les données que vous récupérez de votre base de données (comme les objets auxquels vous les mappez) dans une sorte de couche de cache comme EhCache, OSCache, memcache, etc. - plutôt que de réinventer la roue.

Answer 2

Pourquoi ne pas utiliser hsqldb ou h2?

Ils prennent tous deux en charge le mode en mémoire et sont purs Java. Ils vous forcent à utiliser SQL pour accéder mais à l'autre extrémité, vous n'avez pas à implémenter votre propre jointure.

Les deux sont open source, vous pouvez donc aussi l'utiliser comme référence pour les performances et voir si faire la vôtre par colonne/par structure de données serait plus rapide et en valait la peine.

Answer 3

Une quatrième solution consisterait à stocker les données de chaque ligne sous forme de chaînes au lieu de tableaux d'octets. Cela peut éviter les coûts de sérialisation dans cas les plus - à condition que la plupart des données seront des chaînes.

Cela sera également plus facile à déboguer et sera indépendant de la plate-forme. Bien sûr, il a certaines limitations: par ex. un flottant ne peut pas être représenté tel quel, mais peut être stocké dans quelque chose de similaire à un format SQL DECIMAL.

Toute solution sera un compromis.

EDIT Cependant, je préférerais la solution de tableau d'octets pour votre cas: un octet par rangée. Cela devrait être le plus facile à mettre en cache pour les lignes de taille fixe. Mais vous devez également fournir une solution pour les lignes de taille variable. Un langage de bas niveau semble mieux convenir à cette tâche, dans C on pourrait définir deux formats: lignes de taille fixe où les métadonnées de table contiennent des décalages de colonnes (par exemple colonne 1: octets 0..31, colonne 2: octets 32..127 etc.), et un deuxième format de ligne de taille variable, où les lignes contiennent elles-mêmes les tailles de colonnes (par exemple octets 1..3 contiennent la taille, le nombre suivant d'octets contient les données, puis 4 autres octets contiennent la taille, etc).