I've looked at an JSON implementation on top of SQLite a bit more. It seems
pretty fast. I haven't tried creating JSON indexes, or creating queries that
use them. The only quirk I can find so far is that it treats JSON bool values
into integers. That seems tolerable.
At first blush - without e
This is a CMA dependency only. So, I'm much less concerned about that
than I am for Nanoprobes. Nanoprobes need to run everywhere. The CMA
only needs to run one place in an enterprise.
I think all of these things I'm looking at work well on UNIX-like OSes.
If someone knows differently, please let
I think we should also consider if itll affect what oses we can run this on
if we add x solution. Just want to make sure we dont end up restricting
ourselves too much when adding this dependency.
On Feb 14, 2018 7:41 AM, "Alan Robertson" wrote:
> Hi Clint,
>
> On Wed, Feb 14, 2018, at 7:19 AM, C
Hi Clint,
On Wed, Feb 14, 2018, at 7:19 AM, Clint Byrum wrote:
> Excerpts from Alan Robertson's message of 2018-02-12 19:12:41 -0700:
> > So, that's a total of 4 possible methods of storing the data...
> > (a) in Neo4j, (b) in Postgres, (c) in flat files, (d) in S3. Of those
> > four, only P
Excerpts from Alan Robertson's message of 2018-02-12 19:12:41 -0700:
> So, that's a total of 4 possible methods of storing the data...
> (a) in Neo4j, (b) in Postgres, (c) in flat files, (d) in S3. Of those
> four, only Postgres will provide indexing.
> If on the other hand, we break out big
I wrote some passably reasonable code to persist JSON to disk (using its hash
as a key) as per an off-list suggestion.
You can see it here:
https://github.com/assimilation/assimilation-official/blob/rel_2_dev/cma/invariant_data.py
The base code is very straightforward. It has lots of comments,
Two less heavyweight ways to store the JSON data from some off-list discussions:
1) Just store each JSON value in a flat file. Since the "keys" are already hash
values, one could imagine a directory structure that looks a bit like this:
# T
V2 is in source control as the _rel_2_dev_ branch -- here
https://github.com/assimilation/assimilation-official/tree/rel_2_dev
--
Alan Robertson
al...@unix.sh
On Fri, Feb 9, 2018, at 2:02 PM, N.J. van der Horn (Nico) wrote:
> All efforts to save on resources now, can be profitable in future
Well... I tend to agree. But I need transactions, and also need query
capabilities - which I currently have with only very poor performance (in
addition to the poor write performance). I've been living with the current
circumstances - which for very large updates is really horrible...
Having th
Just intuition here, but embedding postrges inside Assimilation seems heavy for
just JSON. Of course, you already embed neo4j so you know how to handle having
a dependency on a large subsystem.
Then, there's mongodb vs postgres vs ...:
https://www.sisense.com/blog/postgres-vs-mongodb-for-storing
All efforts to save on resources now, can be profitable in future
additions ;-)
Where can I take a peek in V2 ?
Regards, Nico
Op 9-2-2018 om 16:04 schreef Alan Robertson:
> This data is generated by a variety of shell scripts that do discovery -
> potentially dozens of them - and each is differ
This data is generated by a variety of shell scripts that do discovery -
potentially dozens of them - and each is different. Some of the most critical
data is decomposed to attributes - but not most of it.
--
Alan Robertson
al...@unix.sh
On Fri, Feb 9, 2018, at 2:58 AM, Michael Hunger wro
12 matches
Mail list logo
