Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
Reply-To: niclas@hedhman.org
In-Reply-To: <tencent_0BF45BEC05C7D15807D3D15F@qq.com>
References: <tencent_0BF45BEC05C7D15807D3D15F@qq.com>
Date: Tue, 14 Jun 2016 11:02:55 +0800
Message-ID: <CADmm+KfWZib1Zdfny4hVkpfxEfz3T-e1RxoGSvsxBOMxWUAK2g@mail.gmail.com>
Subject: Re: Large Scale Entity Store Database?
From: Niclas Hedhman <hedhman@gmail.com>
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a113ceea6e6e1350535343dc8
archived-at: Tue, 14 Jun 2016 03:03:03 -0000

--001a113ceea6e6e1350535343dc8
Content-Type: text/plain; charset=UTF-8

In Zest, storage/retrieval and indexing/query are separated concerns. (Disk
is cheap)
Just like it is on the world-wide web.

Now, the relatively simple Entity Stores that are based on the
MapEntitStore might be particularly wasteful with storage space, depending
on the underlying engine. However, nothing stops you from creating a
"native" ES for your favorite storage engine.

The Indexing/Query systems are much more complex (compare a website's
store/retrieve with Google's Search) and it is not trivial to make an
indexing extension that is complete (native queries are available as a
compromise).

In Zest 2.x and earlier, the default is to index all properties, and you
can turn some of them off. In 3.x we intend to change the default to off,
and you indicate what needs indexing.

Final note, the requirements on the entity stores are that any "unknown"
state is preserved so that an update will not modify such state. This is
due to the fact that entities of the same identity can have more than one
(possibly incompatible) type. This complicates traditional ORM techniques
quite a bit.

Cheers
Niclas
On Jun 14, 2016 09:06, "zhuangmz08" <zhuangmz08@qq.com> wrote:

> Hi, I dig into the Postgres table, and I find that entities are actually
> stored as JSON-format strings, which seems to use SQL database as a
> Document database. I'm wondering how efficient queries are achieved? I'm
> going to insert and query millions of entities. Have you ever tested the
> performance? Should I use Mongo-support Entity Store instead? Thanks a lot.

--001a113ceea6e6e1350535343dc8--