Grand tableur de données statiques: db relationnel ou fichier plat?

Question

J'ai une feuille de calcul, environ 1500 lignes x 1500 colonnes. Les étiquettes le long du haut et du côté sont les mêmes, et les données dans les cellules sont un score de similarité quantifié pour les deux entrées. Je voudrais créer une application Rails permettant à un utilisateur d'entrer les valeurs de ligne et de colonne et de récupérer le score de similarité. Les scores de similarité ont été dérivés empiriquement et ne peuvent pas être produits mathématiquement par le contrôleur. Quelques considérations: avec chaque cellule pleine, plus de la moitié des données sont redondantes; par exemple, (ligne 34, colonne 985) a la même valeur que (ligne 985, colonne 34). Et la ligne x sera toujours parfaitement similaire à la colonne x. Les données sont statiques et ne changeront pas pendant des années.

Est-ce possible avec une table db? Y a-t-il un meilleur moyen? Puis-je ignorer entièrement la base de données relationnelle et interroger le fichier directement?

Toute l'assistance et les conseils sont très appréciés!

Answer 1

Base de données est toujours un endroit sûr pour le stocker. La base de données relationnelle est simple et une bonne idée. Cependant, il existe des alternatives à considérer. À quelle fréquence ces données seront-elles accessibles? Est-il accessible rarement ou très fréquemment? Si vous y accédez très rarement, placez-le dans la base de données et laissez votre code s'occuper de la recherche et de la présentation. Flat-File est une bonne idée, mais lire et chercher au moment de l'exécution pour chaque requête va être trop lent.

Vous pouvez lire toutes les données (à partir de db/fichier) au démarrage du serveur, et le garder en mémoire et s'assurer que vos serveurs ne redémarrent pas trop souvent. Cela signifie que chacun de vos serveurs va s'asseoir avec toute la grille en mémoire mais le calcul va être très rapide. Si vous utilisez REE et calibrez les paramètres Garbage Collection, vous pouvez également réduire le temps de démarrage du serveur dans une large mesure.

Voici ma dernière suggestion. Construisez simplement votre application de la manière la plus simple possible. Une fois que vous savez combien de fois et combien votre application va être utilisée, vous commencez à optimiser. Vous travaillez fondamentalement avec 1125000 cellules. Ce n'est pas un ensemble de données démesurément grand pour une base de données à traiter. Mais puisque votre jeu de données ne changera pas, vous pouvez aller loin par les techniques de mise en cache classiques.