Arangodb dump query for free#
Arangodb dump query how to#
Arangodb dump query driver#
Arangodb dump query software#

However, it would be naive to say you just designed an ACID complaint KV store by implementing some adhoc KV operations using JSON columns in a RDBMS. It's too expensive to do things properly and customers don't really want that reliability so we can take some risks. In your position I would be honest and say data can be lost or corrupted and thats the price I am willing to pay for flexibility given the resource constraints I have.

Arangodb dump query software#

If your software loses data, they probably won't even notice until they really start to move over for real and lose money (if they did not do testing for consistency). This is perfectly OK at a startup - the customers already depend on a system elsewhere but that system does not meet all their needs so they are experimenting with you but if your company runs to the ground tomorrow, they still have not migrated 100% over to you, so they are 'safe'. Your customers want features over reliability. Been there done that, but not in production. Sure, you're experimenting and things are in a state of flux. > Using the JSON-to-SQL workflow, I can mess around with feature design and iterate fast, and then crystallise the schema into SQL once it has stopped changing. Using the right tool for the right job is what experienced engineers do because it not only makes their lives easier but the businesses they help run more reliable and resilient. They have conflict resolution algorithms, offer CRDTs for the clients to use and engineers who know what they are doing, use them. There are KV-stores out there that handle all these scenarios natively without the client having to worry about it (and doing a halfassed, buggy job about it because they are not DB designers). Database Decomposition is important for a number of reliability reasons. Hint: No it cannot - the reason why a RDBMS can even offer ACID semantics is because RDBMS operations assume certain rules have been followed.

Arangodb dump query how to#

What would happen if I have the different attributes in the same object that I then update one after the other into a JSON column on a RDBMS?ĭoes it fail one of the updates with an error message that data is lost?ĭoes it automagically merge the data? How does it even know how to handle conflicts? What does a KV-store on top of a RDBMS with ACID semantics even mean?ĭoes the RDBMS even supporting merging objects inside a column?

Arangodb dump query for free#

Sure, at a high level, making a KV-store on top of a RDBMS feels like a grand idea - hey you get ACID for free and all the RDBMS goodness while getting the flexibility of a KV-store to boot.Īs they say - when something sounds too good to be true. > you are still getting ACID transactions, envryption, user/access controls, backup/restore, libraries, etc The former is a days worth of work for any good engineer the later can take decades and those people are really hard to find.

Arangodb dump query driver#

Having experience writing postgres client software using some postgres driver is a different kind of experience than installing, provisioning, monitoring and turning postgres itself. I need to understand what 'postgres experience' means in this context.

> in my experience software engineers/data engineers/DBA with postgres experience are easier to find. Hey there, thanks for reading my comments and sharing your thoughts. One of the reasons I backed of Mongo very quickly was the lack of tooling as soon as you have something resembling a schema or relationship and you'd want to change it. So I was hopeful that MongoDB could give me the best of both worlds.

I was using mainly Django with Postgres at the time, but had my career start on ZODB, an object-oriented non-sql database created in the late 90s. When MongoDB first came out, I was eager to check it out. Sure if you take the vanilla databases without their ecosystem, there is some merit to that, but I don't find it a very practical argument to ignore all the tooling and workflows that do exists and are used by people. Among a bunch of other questionable claims. non-sql argument.Īs in you need to switch your entire database system or make a bet on this completely new player instead of battle proven tech, because with relational databases schema migrations are hard. Sure, but almost all the times (I'm not specifically referring to person in the comment I'm responding to and should have been more clear on that) people were making it fundamentally an sql vs.