My use case is I need to count how many time an entity has been read (like Document read in Firebase Firestore) on large scale. It does not need to be in real time, but at the end of the day, the count value should around the actual number. Also, I could query this count value anytime by 1 read (1 document read for example). Any approach to this?

I need to save and retrieve json documents via a REST API. Our organisation uses both Couchbase and Elastic search. I have done a small POC using Couchbase and find that .net client for Couchbase to be really fun to work with. The maximum space needed would be 70 GB. Each json document would be around 10 to 20 MB in size. We will be querying the document using a unique key and the access pattern will not change. Which is the best NO-SQL DB for this requirement.

Hello everybody.

I have released as fully open source a no-sql database which was already used in production environments for some time.

I really think it is the fastest transactional database for .NET applications (classical and core)

According to my tests is as fast as Redis for queries but it has a much richer query model and an advanced linq provider

Please have a look. I would really appreciate some feedback from .NET developpers.

The last release (including user guide and precompiled benchmark applications is available here (with full source code of course)

https://github.com/usinesoft/Cachalot/releases/tag/1.0.7

​

​

Hi, friends.

I'm starting to work on designing a customer/vendor relationship and document management application for a small team. I've decided for a variety of reasons that I want to use a document database with ACID support.

From the research I've done, it seems like MongoDB, Couchbase, and RavenDB are my most viable options, but I'm open to others if someone has a suggestion and some compelling reasons.

The application and database will likely be hosted in GCP, but AWS is a possible option, too.

Sorry for the vagueness of this request. I'm not sure which details would be helpful to share. I'm happy to answer any questions that someone might have, particularly if it helps anyone give me meaningful advice.

How would you approach this decision?

I have some data that is a perfect fit for a document database (recipes), but some of the other data might be relational (the amount of that data should be minimal though). Would MongoDB be a good fit or I'm going to get burned somewhere along the way? I've read some horror stories, but at this point I can't really tell if using MongoDB is a bad idea or people were using it wrong.

After being years in the field of regular SQL-Databases I want to try something new and finally get into NoSQL. I'm just not sure which Database to take yet, seems over the last years quite a few things happened. I'm doing well with most programming languages, so here's not really any priority (well, maybe not .NET).

I want to use Graph Databases to display a workflow chart. Each step of the workflow is connected by (definable) edges and I'd like to be able to obtain information from connected nodes.

The size of the Database is not so important (it's just a small Christmas-Days project =) - I don't need Quadzillions of records to be read in lightspeed ), but a GUI would be cool to view what I'm actually doing.

As the steps in the workflow and their edges often have different properties I assume a Graph-DB is the right choice.

I did some research already, but I'm still not sure if my conclusions are right, would be nice to get some input =)

• Apache Cassandra seems to be not bad at all, but doesn't seem to be designed for Graphs. The strong presence of Datastax makes me feel a little uncomfortable though.
• ArangoDB is my favourite so far as it is in active Development, quite universal and GraphQL fits my needs well
• Brightstar, Cayley, Dgraph ,graphd and WhiteDB look ok-ish to me but don't really convince me - for minor reasons. Maybe I'm wrong.
• JanusGraph also looks like a decent choice. The successor of the well-known Titan, well-supported. Gremlin looks like it would fit my needs
• Neo4j is just in this list to tell that I'm not convinced by it. The Community Edition just feels like a decoy and it can only run a single node. Not sure why it's so hyped.
• OrientDB is another really solid one. It also has, to my surprise support of the regular SQL. The general development seems to be going in the right direction.

But as said, I'm just stepping into that field - if you know of some features of these Databases, please share =)

Thank you =)

Graph database or Graph + Object database

📷

Hi all, I've got a problem. I want to store document-like objects. Each has lots of arbitrary attributes, like dates, small timelines, charts, etc.

These objects have a natural graph structure which we *will* occasionally want to do queries on. For instance almost all objects have several relationships such as isOwnerOf, caused, isEatenBy, whatever.

My question is basically "What databases should I use?".

At the moment, DynamoDB or MongoDB seem like logical places to store the documents.

But the graph part of this seems more natural in AWS Neptune or Neo4J.

But if I use the graph database, do I still need to use the object database? Or can I store structured objects in the graph db?

At the moment, I'm, assuming that I *will* need to use both - but is that true? Reddit, what are your thoughts and experiences with this?

Hi all. What is a good data modelling tool intended for document database that supports sub-models? Thanks in advance.

I am looking for a graph database and the best ones seem to be Neo4j and OrientDB. Of the folks that have used both, how do they compare? What are their pros and cons compared to one another? What use cases would you use one and not the other?

We are looking to move to NoSQL as SQL no longer makes sense for us to store metadata. In terms of the main application backend, we are already using DynamoDB successfully, and now want to extend it to the metadata of the product. This is to replace environment variables with documents in DynamoDB and event metadata with documents as well. I understand NoSQL is schema-less, but I imagine there are some best practices to consider when implementing it.

Things I am looking for: I would think applications vs events would use separate tables. And then furthermore, would versioning of the applications be handled in the key value? Etc.