Can graph databases store JSON?

Question

Database design

Thinking about how to design the system.
The system looks like this - there is an array of data in the form of JSON, which is constantly supplemented.
It is necessary:
​​1. To be able to work with it (search for values, synonyms, returning the found JSON to the user)
2. The data is very similar to those that can be analyzed through graph databases i.e. look for connections, etc.
3. Full-fledged analytics (I don’t know if it can be considered a separate item or it belongs to 1/2)

I still don’t understand in what form graph databases store data. How do they differ from document-oriented. Can graph databases do what I wrote in paragraph 1?

How parallel are these two tasks? If you need both, is it possible to get by with one database or do you need to use two?

Answer 1

It all depends on two things - how much data (the number of objects with meaningful fields) and what kind of analysis needs to be done based on the data. So the question is, how many consumers of this data? Is concurrent read and write access possible (since when parallelism and simultaneous access come into play, everything becomes orders of magnitude more complicated
) solutions, incl. graph databases.
The first will determine, especially if there is very little data, whether independent work in RAM in your application can be more efficient? The fact is that 99% of the reasons why people in the world have developed so many non-simple tools are a large amount of data and high requirements for multi-user access to them, if both of these points are excluded, then it is much more convenient to carry out atypical analysis in your program, keeping the data in RAM (and the database is used solely as fault-tolerant storage).
Personally, I prefer the combination of self-written tools in combination with classic storage (reliability, storage and multi-threaded access). For example, when, due to the peculiarities of the analysis task, sql queries become unbearably complex, their generation comes into play, in the end, many do just that and ready-made solutions are built on the basis of ready-made effective solutions. sql scale well, are easy to use, and don't add any noticeable overhead.
ps json this means that to control the integrity, indexing and search, you will have to fence your add-ons, on the other hand, this frees your hands from unintentionally complicating the storage where it is not required, in general, you need to be careful about this, this is not bad and not good, it's just another way with its pros and cons