J'ai commencé à lire certains des postes liés aux tampons de protocole. La méthode de sérialisation semble très appropriée pour le transfert de données vers et à partir de serveurs Web. Quelqu'un a-t-il envisagé d'utiliser une méthode comme celle-ci pour enregistrer et récupérer des données sur le périphérique mobile lui-même? (C'est-à-dire un remplacement d'une couche de base de données / orm traditionnelle) Nous utilisons actuellement une orje à base de réflexion personnalisée. Nous voulons vous échapper de l'utilisation de la réflexion sur les appareils mobiles. Et, puisque nous devons envoyer / recevoir des données sérialisées de toute façon, cela semble être un bon ajustement.
serait logique de stocker les données dans une base de données traditionnelle (SQLCE ou SQLLITE) avec quelques colonnes "interrogeables", puis une colonne pour les données sérialisées?
pensées? Suis-je dehors sur un membre ici?
Mise à jour: Cette même "théorie" pourrait également fonctionner pour d'autres types de données sérialisées ... JSON par exemple. Je n'ai pas pu trouver une option NOSQL pour stocker et interroger des données sérialisées sur le cadre compact. Je serais également intéressé par cette option si quelqu'un en connaît un.
commentaire sur les bases de données d'objet J'ai essayé à la fois db4o et perstituté. DB4O était absolument merveilleux de travailler avec. Je l'ai utilisé dans la «vie réelle» et la performance, la convivialité et la maintenabilité étaient excellentes. Leurs frais de licence pour notre situation étaient ce que je considérerais scandaleux. Perst était un pas en arrière de DB4O mais aussi merveilleux de travailler avec. Il "vient de travailler" et était rapide (mais pas aussi agréable à interroger.) Leur licence était très abordable, mais quelque chose dans leur licence était inacceptable à la société (grande, bien connue) que je contracte. Cela m'amène où je suis maintenant ...
3 Réponses :
Eh bien, car personne d'autre n'a essayé de répondre à celui-ci, je vais lancer mon opinion. N'oubliez pas que je n'ai jamais utilisé protobuf (c'est pourquoi je n'ai pas répondu déjà), il s'agit donc tout simplement basé sur ma meilleure compréhension des choses et comment, si j'avais ce problème à résoudre, je procéderais. < / p>
Premièrement, j'ai des réservations à propos de coller des blobs dans une base de données relationnelle. Cela peut revenir à mes mauvaises expériences, ce qui est de retour dans la pierre de la VB6 et peut être invalide, mais cela me donne toujours une pause. En tant que tel, j'équelai probablement certains autres mécanismes de stockage d'objets (comme perst ou DB4O ) avant de l'essayer.
Comme diligence raisonnable, j'avais également au moins profil de farce des gouttes dans une base de données SQLCE. Pourquoi SQLCE au lieu de SQLLITE ou d'autres RDM? Eh bien, Becasue Sqlce prend en charge le tableDirect, que je suis un fan énorme de. Chaque fois que vous pouvez accéder aux données sans avoir à utiliser un processeur de requête SLOW-ass, vous êtes de bonne heure.
Donc, je créerais une table, donnez-lui quelques petites colonnes de recherche que je pourrais rechercher sur, puis une colonne d'image qui détient une importante blob binaire (la blob réelle n'est pas pertinente pour le test, mais elle doit être raisonnablement proche de ce que vous attendez en production). J'ajouterais alors des index pour chacune des colonnes de recherche.
Je remplirais la table avec quelques milliers de disques, puis profilez la vitesse à laquelle je pourrais rechercher une clé souhaitée (je sais que c'est rapide) et plus important encore, la vitesse à laquelle je peux réhydrater mes objets.
J'aurais alors peser les coûts (le temps de développer, des coûts d'opportunité, des opportunités de réutilisabilité, etc.) des options et de prendre la décision. Je ferais probablement bloguer les résultats aussi, comme cela ressemble à un problème qui serait d'un intérêt assez large.
Merci pour votre réponse. Voir Notes dans la question originale sur DB4O et PERST. J'ai travaillé sur certaines pistes d'essai utilisant des tampons de protocole ainsi que JSON. Les premiers résultats me donnent de l'espoir et sont nettement plus rapides que la méthodologie de réflexion existante que nous utilisons. Je vais regarder dans les méthodes que vous avez mentionnées pour SQLCE et mettre à jour mes tests. Je vais également envisager votre suggestion de documenter les résultats, dans cette question si nulle part ailleurs.
Je n'ai pas vu cela à l'époque (désolé, mais je ne vois pas toutes les questions, et alors que je regarde la balise En particulier, ce type d'approche centrée sur le document est utile lorsque vous souhaitez réhydrater "le système"; c'est-à-dire l'état entier. Ils ne sont pas aussi simples / flexibles pour interroger ad-hoc qu'une base de données relationnelle. Bien sûr, une option consiste à réhydrater et à interroger en mémoire (par exemple, en C # La requête LinQ-To-Objects sur des données réhydratées serait presque indiscernable d'une requête LINQ-TO-SQL sur les données dans une base de données relationnelle dans une base de données relationnelle dans une base de données relationnelle dans une base de données relationnelle. ). protocouf-net , je ne garde pas aussi vigilente sur protocoles-tampons . Une question très intervérante; en termes de comparaison avec une base de données document (plutôt que relationnel), je pense que ce type d'approche a un grand potentiel. Il semble qu'un petit overkill en regardant relationnel si vous laissez tomber des blobs, mais cela devrait fonctionner au moins. J'ai certainement utilisé des configurations similaires beaucoup pour le chargement de données dans les applications hors ligne - non spécifiquement mobile, mais les mêmes concepts s'appliquent.
Les tests initiaux sont très positifs. J'aimerais faire de plus en plus de benchmarking contre les options d'objet DB ainsi que les différentes autres méthodes que j'ai essayées de comparer les vitesses. J'espère poster des résultats pour que d'autres puissent voir et essayer également.
C'est une question cruciale si vous avez un coup d'œil à Mariadb 10, nous avons introduisons des colonnes dynamiques qui stockent une base de données d'objet structurée dans une blOB https://mariadb.com/kb/en/dynamic-columns/ conversion latérale du client de la goutte à tout ce qui peut être facilité sur le client, car nous avons incorporé l'API dans le C Chauffeur. Je pense que nous n'acceptons que l'exportation JSON, mais avec un petit effort, cela peut probablement être étendu à Protobuf sérialisé, désérialisé.
Je suis surpris du manque de réponse ... pensait que ce serait une excellente question. La question est-elle à la question que je pensais? ;)
@Steve: Je pense en fait que c'est une excellente question. J'ai mes propres théories (que je vais me garder pour moi pour l'instant) mais j'attendais réellement de voir si Marc avait des idées à ce sujet.
@ctacke: Je serais intéressé de connaître vos pensées. Je n'ai reçu aucune réponse et je vais devoir donner mes recommandations bientôt. Je fais des tests et je me sens très bien sur la stratégie, mais j'espérais une certaine sagesse de certains d'entre vous qui ont une grande connaissance et une grande expérience dans ces arènes.