4 ms·

Have you seen RavenDB: https://ravendb.net/ https://ravendb.net/ It's a nosql/multimodal document store written in .NET and supports LINQ-like syntax.

SigmundA 4y ago
Yes not my cup of tea. Had some poor experience with it in the past and don't really like its design philosophy unless somethings changed. Stores data as BSON I believe, which is better than text JSON I guess, but pretty ineffecient compared to something schema based that doesn't have to store keys with values for every every column/property. Didn't like the async indexing with stale results, nice to have as an option but the default should be sync/consistent. Written in .Net but not really using the .Net data type/model, more of a json db, used to use Windows only ESENT data engine but I think they got around to building their own K/V in .Net at some point. I am thinking something more like https://velocitydb.com https://velocitydb.com
- manigandham 4y ago
  RavenDB has changed massively and your assumptions are about 6 years and 2 major versions out of date. I suggest trying it again as none of those are issues anymore. > ".Net but not really using the .Net data type/model" What's that mean? The .NET driver has seamless object persistence.
  - SigmundA 4y ago
    That means at the storage level it's storing a JSON data model not a .Net one. That means the length of a property name matters because its stored with every document rather than having the type info stored in a schema and the individual object instances only storing the values, similar to how a relational db stores columns names in a schema and rows only have data. This can save significant space and overhead. If I am designing a .Net database from scratch with Linq as its target query language then I would want the storage engine to understand and take advantage of types to optimize storage with minimal translation rather than having to serialize/deserialize from .Net to BSON/JSON with key overhead included.
    - manigandham 4y ago
      When you say object "instances" of "types" then what you're referring to is a strong schema. That works in relational databases but RavenDB is a document/schemaless database so there will always be some overhead. RavenDB has collection-level compression across multiple documents which minimizes this: https://ravendb.net/articles/ravendb-5-0-features-smart-document-compression https://ravendb.net/articles/ravendb-5-0-features-smart-docu...
      - SigmundA 4y ago
        >When you say object "instances" of "types" then what you're referring to is a strong schema. Yes that's exactly what I said. .Net is a strongly typed language with a strongly typed data model, hence my point of RavenDB not being a .Net data model even though it's written in .Net. I want a .Net DB that takes advantage of the type system rather than a JSON DB I can access with a .Net client, there are plenty of those. Document compression with dictionary training in a schemaless databases is a bandaid over their fact there is no schema. A Relational DB saves a ton of space with increased performance and lower CPU (rather than decreased performance and higher CPU with compression) because it has a strongly typed schema and therefore does not need to read/write the column names and types for every row and it can serialize column data to their most efficient form based on the type. This sort of efficiency flows through the entire system including better cache utilization, smaller indexes, and less data sent over the wire to the client. You can still do compression on top of a schema for even more savings like most DB's but you can do even more interesting storage techniques like column storage vs row storage if you have a schema that can really save space and increase performance depending on usage. A .Net DB could similar things again because if a strong type system. RavenDB looks like it has come a long way and Ayende definitely knows databases and .Net, however I am not a big fan of the JSON/document database philosophy, just my option based on experience. I prefer a strongly typed system that has an untyped escape hatch when needed, like PG with JSONB columns. That way you can stick to strong types and loose documents sparingly when needed. In a .Net DB that would be dynamic types being transparently stored with a loss of efficiency.
        4y ago

SigmundA 4y ago

Yes not my cup of tea. Had some poor experience with it in the past and don't really like its design philosophy unless somethings changed. Stores data as BSON I believe, which is better than text JSON I guess, but pretty ineffecient compared to something schema based that doesn't have to store keys with values for every every column/property. Didn't like the async indexing with stale results, nice to have as an option but the default should be sync/consistent. Written in .Net but not really using the .Net data type/model, more of a json db, used to use Windows only ESENT data engine but I think they got around to building their own K/V in .Net at some point. I am thinking something more like https://velocitydb.com https://velocitydb.com

manigandham 4y ago
RavenDB has changed massively and your assumptions are about 6 years and 2 major versions out of date. I suggest trying it again as none of those are issues anymore. > ".Net but not really using the .Net data type/model" What's that mean? The .NET driver has seamless object persistence.
- SigmundA 4y ago
  That means at the storage level it's storing a JSON data model not a .Net one. That means the length of a property name matters because its stored with every document rather than having the type info stored in a schema and the individual object instances only storing the values, similar to how a relational db stores columns names in a schema and rows only have data. This can save significant space and overhead. If I am designing a .Net database from scratch with Linq as its target query language then I would want the storage engine to understand and take advantage of types to optimize storage with minimal translation rather than having to serialize/deserialize from .Net to BSON/JSON with key overhead included.
  - manigandham 4y ago
    When you say object "instances" of "types" then what you're referring to is a strong schema. That works in relational databases but RavenDB is a document/schemaless database so there will always be some overhead. RavenDB has collection-level compression across multiple documents which minimizes this: https://ravendb.net/articles/ravendb-5-0-features-smart-document-compression https://ravendb.net/articles/ravendb-5-0-features-smart-docu...
    - SigmundA 4y ago
      >When you say object "instances" of "types" then what you're referring to is a strong schema. Yes that's exactly what I said. .Net is a strongly typed language with a strongly typed data model, hence my point of RavenDB not being a .Net data model even though it's written in .Net. I want a .Net DB that takes advantage of the type system rather than a JSON DB I can access with a .Net client, there are plenty of those. Document compression with dictionary training in a schemaless databases is a bandaid over their fact there is no schema. A Relational DB saves a ton of space with increased performance and lower CPU (rather than decreased performance and higher CPU with compression) because it has a strongly typed schema and therefore does not need to read/write the column names and types for every row and it can serialize column data to their most efficient form based on the type. This sort of efficiency flows through the entire system including better cache utilization, smaller indexes, and less data sent over the wire to the client. You can still do compression on top of a schema for even more savings like most DB's but you can do even more interesting storage techniques like column storage vs row storage if you have a schema that can really save space and increase performance depending on usage. A .Net DB could similar things again because if a strong type system. RavenDB looks like it has come a long way and Ayende definitely knows databases and .Net, however I am not a big fan of the JSON/document database philosophy, just my option based on experience. I prefer a strongly typed system that has an untyped escape hatch when needed, like PG with JSONB columns. That way you can stick to strong types and loose documents sparingly when needed. In a .Net DB that would be dynamic types being transparently stored with a loss of efficiency.
      - 4y ago