polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: 回复: Large Scale Entity Store Database?
Date Tue, 14 Jun 2016 07:17:52 GMT
Hi,

zhuangmz08 a écrit :
> Hi, 
>
>
> OK, writing entities and reading entities are separated both theroy and physical implementation.

Entities are written *and* fetched from EntityStores.
Entities are indexed into index/query engines.
Queries are resolved by index/query engines that only returns
identities, used to fetch the actual entities from EntityStores.

> 1. It's acceptable to occupy large storage space (Disk is cheap).
> All entities are stored in a SINGLE table of the SQL database or in a SINGLE collection
of the SINGLE database in Mongo.
> What's the key factors on writing? Which MapEntityStore is faster in writing entities?
I mean, which is better for production use.
Just like Niclas said, most of the EntityStores are based on
JSONMapEntityStore, so they are built as simple key/value stores
whichever is the underlying storage system. SQL ES use a single table,
Mongo ES use a single collection and so on. Which one is best for your
use case depends on your application and deployment constraints. I
successfuly used File ES, SQL ES, Mongo ES and Redis ES in production, YMMV.

> 2. Reading speed is related to the Indexer?  I know something about search engine (Apache
Solr). Could you explain more about the querying. When the query string matched some index,
how will they interact with the entity database? Do we need to query the Entity database internally?
I would like to know the factors impacting read speed.
> Which is better for production use, OpenRDF or ElasticSearch?

Indexing and querying speed is related to the Index/Query engine.
Fetching speed is related to the EntityStore.

In any case, I'd suggest that you run speed/load tests on your
application. Zest strength here is that you can cheaply change your
EntityStore / Index/Query engines.

HTH

/Paul


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message