I have a few questions about storage overhead in ODB. If this is in the documentation somewhere, I've not been able to find it.
1. What is the overhead (in bytes) to store any document (V or E), regardless of any property data (and not including indices, if any)? 2. If non-mandatory properties are defined in the schema but not created/stored, is there any per-document overhead for those properties? 3. For a given property type (BYTE, SHORT, INTEGER, STRING, etc.) what is the overhead for each (i.e. a SHORT is two bytes, but how many actual bytes are written to storage for each SHORT in a given document)? 4. Are there any best-practices to minimize storage overhead (obviously, using the smallest property type for the job is key, but beyond that)? I'm asking because I have an application that needs to store a very large number (billions) of relatively small documents (i.e. they have only three or four SHORT or INTEGER values), so storage overhead becomes very important in planning for system scalability. My current database architecture uses lightweight links between the "root/owner" vertexes (of which there are only hundreds of thousands) and the "data" vertexes (of which there will be billions over time). I had also considered doing this using embedded documents, except that "data" vertexes will sometimes (often) need to link to other "data" vertexes, not just from the "root" to the "data", so using lightweight edges seemed like a better approach. If anyone has any insight or comments on this, I'd love to hear them. --Eric -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
