@Gari,

There will be multiple index keys created for a single object. In fact, sometimes even multiple keys for single field which has multiple values. So, It will be highly redundant if I store data directly in those keys, hence using a pointing mechanism for the same.

@ Manish, 

Thanks for the response. 

1. That makes sense.

2. I agree, doing it in chaincode is not the best way, but it think it is the simpler way for still gaining some significant performance. Especially, for a frequently used casual query, which would return very less data. Earlier, I have been using composite keys with fields ordered in their significance of query necessity(Eg: Doctype at first always, Id will be second) and had a query processor at chaincode itself, that would take fetch all the records with the given docType and parse, in case the fields that you want to query is discontinued when forming as composite keys (Eg: doctype: doc1, Id:" ", count: 1000).

It also helps for relational queries. 

The main problem with this is that, when doing the above mentioned type query, there will be no best case, average case, All such queries run on worst case and directly proportional to the number of records in that docType. (eg: For 100k records, it takes 6 seconds to return response, no matter if it will return a single result or all 100k records as result).

Then, I also compared couch Db's performance with the same data sets, for un-indexed queries‌, it was slower than leveldb. Indexed queries were faster as long as it did not return like all of 100k records, and writes were far far slower than leveldb. Hence, this project was thought out, which could be a helpful and easy workaround until fabric gets this.

3. Yes, I am using a 7200RPM hdd. I agree it has got to be slower. I have also casually tested mounting a volume directly in memory and using it as the mount folder for /var/production. I did not see a significant improvement. I did not check it thoroughly though, it could also be bottleneck in my code. 

I am also storing meta data similar to cost model as you mentioned, which is used to choose the query field which would have least number of records and then doing further processing at code. Thanks for mentioning this, I think its a good idea to skip indexing altogether in some cases.

The next step for me is to build proper cache for the data in memory. I've implemented a simple one and tested it out, it has 40% improvement in the worst case scenario when compared to the old composite key implementation. 

To maintain reliability of the cached data: 

1. Will stored hash of actual data in index keys.

2. Will always fetch index keys from db, and verify if the hash in it and hash of data in cache are same. 

If same, then no change has occurred to data and will use the same.

Else, I will fetch the latest data from db. This ensures consistency.

I have questions in caching. 

1. I have read that in old version of fabric, chaincode container is stopped when idling. Is it still the case in 1.3+ versions? 

2. Is it ok to save decrypted data in memory?

- Prasanth

On Mon, 6 Apr 2020, 8:10 pm Manish Sethi, <manish.sethi@...> wrote:

Hello Prasanth,

Aw

My response to your questions would be three fold.

First, a chaincode is expected to be a sequential logic. Otherwise, providing a guarantee of deterministic behavior is very hard. If you go into theoretical aspects, the basic definition of a transaction is "a sequence of database operations….” - a logical sequence is key here. There are some mature systems that support nested transactions that could be executed in parallel but to keep the chaincode logic simple and deterministic, Fabric supports it in the form of a single sequential flow.

Second, for complex query support, you are experimenting in the right direction at a high level. However, implementing it on the chaincode side is not going to be efficient and ideally be implemented on the Fabric side. Since beginning, we have similar ideas to build a query engine on top, albeit on the Fabric side - however, this did not reach in the top of the priority list.

Third, on the performance behavior that you are observing - one of the main reason of this observation is that the random access is significantly costly in the terms of I/O. I am not sure what storage are you using but this would be magnified if you are using rotating hard disks as opposed to SSD. Similarly, this is going to be magnified if you measure this on the chaincode side as opposed to when implemented on the Fabric side. In general, this is a well understood behavior in traditional and mature databases that using an index is not always helpful and at times the using the index could in fact be more costly than scanning the whole data and filter what is not needed. For instance, if you employ a rotating disk and the data items that you need to retrieve is uniformly spread across in the entire range, and the data items that satisfy the query are more than 10% of the total data, you would perhaps be better off scanning full data than using the index. Most of the query engines employ a sophisticated cost model that estimates the cost of various potential query execution plans and select the one that appears to be the least expensive for the given query in the context of the data present. Most of the cost models maintains some metadata to derive some of these heuristics.

Thanks,

Manish

On Sun, Apr 5, 2020 at 4:02 PM Prasanth Sundaravelu <prasanths96@...> wrote:

Hi guys,

I have been recently developing custom rich query processor & indexing mechanism at chaincode level to exploit goleveldb's performance. I have designed this on the assumption that getting series of keys by GetStateByRange() and regular GetState() will be the same, but I could see now, that the range query is much faster. It makes sense as range query will read the storage in a sequential way and GetState() has to jump to different memory locations to fetch (Correct me if I am wrong). 

I have partially implemented it to be able to test the underlying design assumptions and I am in trouble now. 
The logic of the query operation is like this: 
1. Based on the query, make a range query on the relevant indexes.
2. After retrieving indexes, fetch the actual data pointed by the index using GetState().

This works charmingly well, if the number of matching records is less, but horrible if the record count is high:

- For a response with 1 record, it takes under ~30ms. 
- For 100 records: ~100ms
- For 1000 records: ~1sec! (See the trouble?)

I can see that the bottleneck is at the GetState(). I would like to have some pointers to resolve this issue. 
I have tried the following: 
- In range query, fetched a single iterator, synchronized it and fed it to multiple go routines. (Which doesn't improve the performance of range query at all, since it's still reading one at a time)
- Tried to get multiple iterators, but fabric threw error if I do that.
- Tried to run GetState() on multiple go routines. Still no improvement. 

I have the following questions:
1. Is the fabric running chaincode itself as a whole already as go routines? If so, does it help chaincode functions by default?
2. If having Go Routines in chaincode help at all? 
3. How can I make GetState() faster?

Pardon my long message. 

If you're interested in this project, you can help me implementing this by contributing: https://github.com/prasanths96/iState
This is my first open project, I would really appreciate comments and critiques that would positively impact the project. Suggestions are welcome.
More about the project: 
- Supports json like rich query in leveldb. (As the couch DB's performance is not "good enough")
- It aims to be a work around that can be easily used by any chaincode developer.
- In-memory cached data is going to be a feature that would increase the query performance to atleast 10 folds. 
- All this delivered as an interface to developers having simple CRUD functions.

- Prasanth

I'll just add two more points...

First, although it would increase the size of your chaincode created 'indexes', you could choose to include the base data that you need to retrieve in the index key's value, so that the range scan results can be used directly rather than having to do an additional GetState query. In the database world, this is called an INCLUDE in the index, as explained from PostreSQL as follows:
"The optional INCLUDE clause specifies a list of columns which will be included in the index as non-key columns. A non-key column cannot be used in an index scan search qualification, and it is disregarded for purposes of any uniqueness or exclusion constraint enforced by the index. However, an index-only scan can return the contents of non-key columns without having to visit the index's table, since they are available directly from the index entry. Thus, addition of non-key columns allows index-only scans to be used for queries that otherwise could not use them."
Of course, this may imply that you store the same base data in multiple 'indexes', so you'll have to balance the considerations.

Second, you can always decide to load balance queries across a number of peers, if you can find a way to split the query into multiple queries from the client perspective.


Dave Enyeart

"Manish" ---04/06/2020 10:56:26 AM---I would further like to elaborate on my first point as it may cause confusion in the context of Fabr

From: "Manish" <manish.sethi@...>
To: Prasanth Sundaravelu <prasanths96@...>
Cc: fabric@...
Date: 04/06/2020 10:56 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Go routines in chaincode helps? (especially with GetState() and GetStateByRange() APIs #fabric #hyperledger-fabric #fabric-questions
Sent by: fabric@...

---

I would further like to elaborate on my first point as it may cause confusion in the context of Fabric….
Like most of the other databases, Fabric 0.6 transaction semantics were to support read-your-own-writes (RYOW). With these semantics, it matters whether in the sequence of transaction, you performed a read or a write first. The query results may differ based on the sequence of operations.

However, with Fabric 1.0, we did not support RYOW and hence, there is no theoretical bottleneck to support parallel queries as such.

On Mon, Apr 6, 2020 at 10:40 AM Manish Sethi <manish.sethi@...> wrote:

Hello Prasanth,

My response to your questions would be three fold.

First, a chaincode is expected to be a sequential logic. Otherwise, providing a guarantee of deterministic behavior is very hard. If you go into theoretical aspects, the basic definition of a transaction is "a sequence of database operations….” - a logical sequence is key here. There are some mature systems that support nested transactions that could be executed in parallel but to keep the chaincode logic simple and deterministic, Fabric supports it in the form of a single sequential flow.

Second, for complex query support, you are experimenting in the right direction at a high level. However, implementing it on the chaincode side is not going to be efficient and ideally be implemented on the Fabric side. Since beginning, we have similar ideas to build a query engine on top, albeit on the Fabric side - however, this did not reach in the top of the priority list.

Third, on the performance behavior that you are observing - one of the main reason of this observation is that the random access is significantly costly in the terms of I/O. I am not sure what storage are you using but this would be magnified if you are using rotating hard disks as opposed to SSD. Similarly, this is going to be magnified if you measure this on the chaincode side as opposed to when implemented on the Fabric side. In general, this is a well understood behavior in traditional and mature databases that using an index is not always helpful and at times the using the index could in fact be more costly than scanning the whole data and filter what is not needed. For instance, if you employ a rotating disk and the data items that you need to retrieve is uniformly spread across in the entire range, and the data items that satisfy the query are more than 10% of the total data, you would perhaps be better off scanning full data than using the index. Most of the query engines employ a sophisticated cost model that estimates the cost of various potential query execution plans and select the one that appears to be the least expensive for the given query in the context of the data present. Most of the cost models maintains some metadata to derive some of these heuristics.

Thanks,
Manish





On Sun, Apr 5, 2020 at 4:02 PM Prasanth Sundaravelu <prasanths96@...> wrote:
Hi guys,

I have been recently developing custom rich query processor & indexing mechanism at chaincode level to exploit goleveldb's performance. I have designed this on the assumption that getting series of keys by GetStateByRange() and regular GetState() will be the same, but I could see now, that the range query is much faster. It makes sense as range query will read the storage in a sequential way and GetState() has to jump to different memory locations to fetch (Correct me if I am wrong). 

I have partially implemented it to be able to test the underlying design assumptions and I am in trouble now. 
The logic of the query operation is like this: 
1. Based on the query, make a range query on the relevant indexes.
2. After retrieving indexes, fetch the actual data pointed by the index using GetState().

This works charmingly well, if the number of matching records is less, but horrible if the record count is high:

- For a response with 1 record, it takes under ~30ms. 
- For 100 records: ~100ms
- For 1000 records: ~1sec! (See the trouble?)

I can see that the bottleneck is at the GetState(). I would like to have some pointers to resolve this issue. 
I have tried the following: 
- In range query, fetched a single iterator, synchronized it and fed it to multiple go routines. (Which doesn't improve the performance of range query at all, since it's still reading one at a time)
- Tried to get multiple iterators, but fabric threw error if I do that.
- Tried to run GetState() on multiple go routines. Still no improvement. 

I have the following questions:
1. Is the fabric running chaincode itself as a whole already as go routines? If so, does it help chaincode functions by default?
2. If having Go Routines in chaincode help at all? 
3. How can I make GetState() faster?

Pardon my long message. 


If you're interested in this project, you can help me implementing this by contributing: https://github.com/prasanths96/iState
This is my first open project, I would really appreciate comments and critiques that would positively impact the project. Suggestions are welcome.
More about the project: 
- Supports json like rich query in leveldb. (As the couch DB's performance is not "good enough")
- It aims to be a work around that can be easily used by any chaincode developer.
- In-memory cached data is going to be a feature that would increase the query performance to atleast 10 folds. 
- All this delivered as an interface to developers having simple CRUD functions.

- Prasanth

Hello Prasanth,

Aw

My response to your questions would be three fold.

First, a chaincode is expected to be a sequential logic. Otherwise, providing a guarantee of deterministic behavior is very hard. If you go into theoretical aspects, the basic definition of a transaction is "a sequence of database operations….” - a logical sequence is key here. There are some mature systems that support nested transactions that could be executed in parallel but to keep the chaincode logic simple and deterministic, Fabric supports it in the form of a single sequential flow.

Second, for complex query support, you are experimenting in the right direction at a high level. However, implementing it on the chaincode side is not going to be efficient and ideally be implemented on the Fabric side. Since beginning, we have similar ideas to build a query engine on top, albeit on the Fabric side - however, this did not reach in the top of the priority list.

Third, on the performance behavior that you are observing - one of the main reason of this observation is that the random access is significantly costly in the terms of I/O. I am not sure what storage are you using but this would be magnified if you are using rotating hard disks as opposed to SSD. Similarly, this is going to be magnified if you measure this on the chaincode side as opposed to when implemented on the Fabric side. In general, this is a well understood behavior in traditional and mature databases that using an index is not always helpful and at times the using the index could in fact be more costly than scanning the whole data and filter what is not needed. For instance, if you employ a rotating disk and the data items that you need to retrieve is uniformly spread across in the entire range, and the data items that satisfy the query are more than 10% of the total data, you would perhaps be better off scanning full data than using the index. Most of the query engines employ a sophisticated cost model that estimates the cost of various potential query execution plans and select the one that appears to be the least expensive for the given query in the context of the data present. Most of the cost models maintains some metadata to derive some of these heuristics.

Thanks,

Manish

On Sun, Apr 5, 2020 at 4:02 PM Prasanth Sundaravelu <prasanths96@...> wrote:

Hi guys,

I have been recently developing custom rich query processor & indexing mechanism at chaincode level to exploit goleveldb's performance. I have designed this on the assumption that getting series of keys by GetStateByRange() and regular GetState() will be the same, but I could see now, that the range query is much faster. It makes sense as range query will read the storage in a sequential way and GetState() has to jump to different memory locations to fetch (Correct me if I am wrong). 

I have partially implemented it to be able to test the underlying design assumptions and I am in trouble now. 
The logic of the query operation is like this: 
1. Based on the query, make a range query on the relevant indexes.
2. After retrieving indexes, fetch the actual data pointed by the index using GetState().

This works charmingly well, if the number of matching records is less, but horrible if the record count is high:

- For a response with 1 record, it takes under ~30ms. 
- For 100 records: ~100ms
- For 1000 records: ~1sec! (See the trouble?)

I can see that the bottleneck is at the GetState(). I would like to have some pointers to resolve this issue. 
I have tried the following: 
- In range query, fetched a single iterator, synchronized it and fed it to multiple go routines. (Which doesn't improve the performance of range query at all, since it's still reading one at a time)
- Tried to get multiple iterators, but fabric threw error if I do that.
- Tried to run GetState() on multiple go routines. Still no improvement. 

I have the following questions:
1. Is the fabric running chaincode itself as a whole already as go routines? If so, does it help chaincode functions by default?
2. If having Go Routines in chaincode help at all? 
3. How can I make GetState() faster?

Pardon my long message. 

If you're interested in this project, you can help me implementing this by contributing: https://github.com/prasanths96/iState
This is my first open project, I would really appreciate comments and critiques that would positively impact the project. Suggestions are welcome.
More about the project: 
- Supports json like rich query in leveldb. (As the couch DB's performance is not "good enough")
- It aims to be a work around that can be easily used by any chaincode developer.
- In-memory cached data is going to be a feature that would increase the query performance to atleast 10 folds. 
- All this delivered as an interface to developers having simple CRUD functions.

- Prasanth

I would further like to elaborate on my first point as it may cause confusion in the context of Fabric….

Like most of the other databases, Fabric 0.6 transaction semantics were to support read-your-own-writes (RYOW). With these semantics, it matters whether in the sequence of transaction, you performed a read or a write first. The query results may differ based on the sequence of operations.

However, with Fabric 1.0, we did not support RYOW and hence, there is no theoretical bottleneck to support parallel queries as such.

On Mon, Apr 6, 2020 at 10:40 AM Manish Sethi <manish.sethi@...> wrote:

Hello Prasanth,

My response to your questions would be three fold.

First, a chaincode is expected to be a sequential logic. Otherwise, providing a guarantee of deterministic behavior is very hard. If you go into theoretical aspects, the basic definition of a transaction is "a sequence of database operations….” - a logical sequence is key here. There are some mature systems that support nested transactions that could be executed in parallel but to keep the chaincode logic simple and deterministic, Fabric supports it in the form of a single sequential flow.

Second, for complex query support, you are experimenting in the right direction at a high level. However, implementing it on the chaincode side is not going to be efficient and ideally be implemented on the Fabric side. Since beginning, we have similar ideas to build a query engine on top, albeit on the Fabric side - however, this did not reach in the top of the priority list.

Third, on the performance behavior that you are observing - one of the main reason of this observation is that the random access is significantly costly in the terms of I/O. I am not sure what storage are you using but this would be magnified if you are using rotating hard disks as opposed to SSD. Similarly, this is going to be magnified if you measure this on the chaincode side as opposed to when implemented on the Fabric side. In general, this is a well understood behavior in traditional and mature databases that using an index is not always helpful and at times the using the index could in fact be more costly than scanning the whole data and filter what is not needed. For instance, if you employ a rotating disk and the data items that you need to retrieve is uniformly spread across in the entire range, and the data items that satisfy the query are more than 10% of the total data, you would perhaps be better off scanning full data than using the index. Most of the query engines employ a sophisticated cost model that estimates the cost of various potential query execution plans and select the one that appears to be the least expensive for the given query in the context of the data present. Most of the cost models maintains some metadata to derive some of these heuristics.

Thanks,

Manish

On Sun, Apr 5, 2020 at 4:02 PM Prasanth Sundaravelu <prasanths96@...> wrote:

Hi guys,

I have been recently developing custom rich query processor & indexing mechanism at chaincode level to exploit goleveldb's performance. I have designed this on the assumption that getting series of keys by GetStateByRange() and regular GetState() will be the same, but I could see now, that the range query is much faster. It makes sense as range query will read the storage in a sequential way and GetState() has to jump to different memory locations to fetch (Correct me if I am wrong). 

I have partially implemented it to be able to test the underlying design assumptions and I am in trouble now. 
The logic of the query operation is like this: 
1. Based on the query, make a range query on the relevant indexes.
2. After retrieving indexes, fetch the actual data pointed by the index using GetState().

This works charmingly well, if the number of matching records is less, but horrible if the record count is high:

- For a response with 1 record, it takes under ~30ms. 
- For 100 records: ~100ms
- For 1000 records: ~1sec! (See the trouble?)

I can see that the bottleneck is at the GetState(). I would like to have some pointers to resolve this issue. 
I have tried the following: 
- In range query, fetched a single iterator, synchronized it and fed it to multiple go routines. (Which doesn't improve the performance of range query at all, since it's still reading one at a time)
- Tried to get multiple iterators, but fabric threw error if I do that.
- Tried to run GetState() on multiple go routines. Still no improvement. 

I have the following questions:
1. Is the fabric running chaincode itself as a whole already as go routines? If so, does it help chaincode functions by default?
2. If having Go Routines in chaincode help at all? 
3. How can I make GetState() faster?

Pardon my long message. 

If you're interested in this project, you can help me implementing this by contributing: https://github.com/prasanths96/iState
This is my first open project, I would really appreciate comments and critiques that would positively impact the project. Suggestions are welcome.
More about the project: 
- Supports json like rich query in leveldb. (As the couch DB's performance is not "good enough")
- It aims to be a work around that can be easily used by any chaincode developer.
- In-memory cached data is going to be a feature that would increase the query performance to atleast 10 folds. 
- All this delivered as an interface to developers having simple CRUD functions.

- Prasanth

Hello Prasanth,

My response to your questions would be three fold.

First, a chaincode is expected to be a sequential logic. Otherwise, providing a guarantee of deterministic behavior is very hard. If you go into theoretical aspects, the basic definition of a transaction is "a sequence of database operations….” - a logical sequence is key here. There are some mature systems that support nested transactions that could be executed in parallel but to keep the chaincode logic simple and deterministic, Fabric supports it in the form of a single sequential flow.

Second, for complex query support, you are experimenting in the right direction at a high level. However, implementing it on the chaincode side is not going to be efficient and ideally be implemented on the Fabric side. Since beginning, we have similar ideas to build a query engine on top, albeit on the Fabric side - however, this did not reach in the top of the priority list.

Third, on the performance behavior that you are observing - one of the main reason of this observation is that the random access is significantly costly in the terms of I/O. I am not sure what storage are you using but this would be magnified if you are using rotating hard disks as opposed to SSD. Similarly, this is going to be magnified if you measure this on the chaincode side as opposed to when implemented on the Fabric side. In general, this is a well understood behavior in traditional and mature databases that using an index is not always helpful and at times the using the index could in fact be more costly than scanning the whole data and filter what is not needed. For instance, if you employ a rotating disk and the data items that you need to retrieve is uniformly spread across in the entire range, and the data items that satisfy the query are more than 10% of the total data, you would perhaps be better off scanning full data than using the index. Most of the query engines employ a sophisticated cost model that estimates the cost of various potential query execution plans and select the one that appears to be the least expensive for the given query in the context of the data present. Most of the cost models maintains some metadata to derive some of these heuristics.

Thanks,

Manish

On Sun, Apr 5, 2020 at 4:02 PM Prasanth Sundaravelu <prasanths96@...> wrote:

Hi guys,

I have been recently developing custom rich query processor & indexing mechanism at chaincode level to exploit goleveldb's performance. I have designed this on the assumption that getting series of keys by GetStateByRange() and regular GetState() will be the same, but I could see now, that the range query is much faster. It makes sense as range query will read the storage in a sequential way and GetState() has to jump to different memory locations to fetch (Correct me if I am wrong). 

I have partially implemented it to be able to test the underlying design assumptions and I am in trouble now. 
The logic of the query operation is like this: 
1. Based on the query, make a range query on the relevant indexes.
2. After retrieving indexes, fetch the actual data pointed by the index using GetState().

This works charmingly well, if the number of matching records is less, but horrible if the record count is high:

- For a response with 1 record, it takes under ~30ms. 
- For 100 records: ~100ms
- For 1000 records: ~1sec! (See the trouble?)

I can see that the bottleneck is at the GetState(). I would like to have some pointers to resolve this issue. 
I have tried the following: 
- In range query, fetched a single iterator, synchronized it and fed it to multiple go routines. (Which doesn't improve the performance of range query at all, since it's still reading one at a time)
- Tried to get multiple iterators, but fabric threw error if I do that.
- Tried to run GetState() on multiple go routines. Still no improvement. 

I have the following questions:
1. Is the fabric running chaincode itself as a whole already as go routines? If so, does it help chaincode functions by default?
2. If having Go Routines in chaincode help at all? 
3. How can I make GetState() faster?

Pardon my long message. 

If you're interested in this project, you can help me implementing this by contributing: https://github.com/prasanths96/iState
This is my first open project, I would really appreciate comments and critiques that would positively impact the project. Suggestions are welcome.
More about the project: 
- Supports json like rich query in leveldb. (As the couch DB's performance is not "good enough")
- It aims to be a work around that can be easily used by any chaincode developer.
- In-memory cached data is going to be a feature that would increase the query performance to atleast 10 folds. 
- All this delivered as an interface to developers having simple CRUD functions.

- Prasanth

Hi guys,

I have been recently developing custom rich query processor & indexing mechanism at chaincode level to exploit goleveldb's performance. I have designed this on the assumption that getting series of keys by GetStateByRange() and regular GetState() will be the same, but I could see now, that the range query is much faster. It makes sense as range query will read the storage in a sequential way and GetState() has to jump to different memory locations to fetch (Correct me if I am wrong). 

I have partially implemented it to be able to test the underlying design assumptions and I am in trouble now. 
The logic of the query operation is like this: 
1. Based on the query, make a range query on the relevant indexes.
2. After retrieving indexes, fetch the actual data pointed by the index using GetState().

This works charmingly well, if the number of matching records is less, but horrible if the record count is high:

- For a response with 1 record, it takes under ~30ms. 
- For 100 records: ~100ms
- For 1000 records: ~1sec! (See the trouble?)

I can see that the bottleneck is at the GetState(). I would like to have some pointers to resolve this issue. 
I have tried the following: 
- In range query, fetched a single iterator, synchronized it and fed it to multiple go routines. (Which doesn't improve the performance of range query at all, since it's still reading one at a time)
- Tried to get multiple iterators, but fabric threw error if I do that.
- Tried to run GetState() on multiple go routines. Still no improvement. 

I have the following questions:
1. Is the fabric running chaincode itself as a whole already as go routines? If so, does it help chaincode functions by default?
2. If having Go Routines in chaincode help at all? 
3. How can I make GetState() faster?

Pardon my long message. 

If you're interested in this project, you can help me implementing this by contributing: https://github.com/prasanths96/iState
This is my first open project, I would really appreciate comments and critiques that would positively impact the project. Suggestions are welcome.
More about the project: 
- Supports json like rich query in leveldb. (As the couch DB's performance is not "good enough")
- It aims to be a work around that can be easily used by any chaincode developer.
- In-memory cached data is going to be a feature that would increase the query performance to atleast 10 folds. 
- All this delivered as an interface to developers having simple CRUD functions.

- Prasanth