Show HN: Fast database for React Native with multiple data-type support

#1

Post by ammarahm-ed » Sat, Mar 21, 2020, 3:19 PM UTC

Show HN: Fast database for React Native with multiple data-type support
github.com

Re: Show HN: Fast database for React Native with multiple data-type support

#2

Post by tomovo » Sat, Mar 21, 2020, 6:03 PM UTC

In the iOS implementation, a new dispatch queue is created on each 'set' or 'get' call, from which it switches to the main queue to call MMKV, wrapped in a try/catch block.

Inside the MMKV library, a NSData object is created, another class is used to write a single "int" value to it, then the data object is used as the "raw" value for the given key.

I haven't looked any futher but already this seems like a lot of work to set a number in memory. Is there any reason for this?

Re: Show HN: Fast database for React Native with multiple data-type support

#3

Post by jitl » Sat, Mar 21, 2020, 6:16 PM UTC

I’m surprised to not find any iteration or query primitives. No key scanning?

Re: Show HN: Fast database for React Native with multiple data-type support

#4

Post by theyoungwolf » Sat, Mar 21, 2020, 7:26 PM UTC

can someone tell me what this is used for? Is this like a replacement for localstorage?

Re: Show HN: Fast database for React Native with multiple data-type support

#5

Post by ammarahmed6506 » Sat, Mar 21, 2020, 7:41 PM UTC

theyoungwolf wrote: post #4

can someone tell me what this is used for? Is this like a replacement for localstorage?

Yes its a replacment, a very fast one with all datatypes support, not only strings.

Re: Show HN: Fast database for React Native with multiple data-type support

#6

Post by ammarahmed6506 » Sat, Mar 21, 2020, 7:43 PM UTC

jitl wrote: post #3

I’m surprised to not find any iteration or query primitives. No key scanning?

MMKV is a simple key-value store but the good thing is that it is fast, A custom indexer can be made for querying. However there is a method to get all the keys in the storage but its not exposed in react native side. Is that what you mean?

Re: Show HN: Fast database for React Native with multiple data-type support

#7

Post by ammarahmed6506 » Sat, Mar 21, 2020, 7:46 PM UTC

tomovo wrote: post #2

In the iOS implementation, a new dispatch queue is created on each 'set' or 'get' call, from which it switches to the main queue to call MMKV, wrapped in a try/catch block. Inside the MMKV library, a NSData object is created, another class is used to write a single "int" value to it, then the data object is used as the "raw" value for the given key. I haven't looked any futher but already this seems like a lot of wor…

I think you are right. I was focusing on basic implementation. Now I will make the performance optimizations needed. For example using a single instance of created class for all get set methods and not create them on every call. Thanks for pointing it out.

The second thing about numbers is that its just in case you needed it for something, it is there but there are other ways to set the data too.

Re: Show HN: Fast database for React Native with multiple data-type support

#8

Post by jiofih » Sat, Mar 21, 2020, 8:32 PM UTC

Why use this over SQLite?

Re: Show HN: Fast database for React Native with multiple data-type support

#9

Post by mpweiher » Sat, Mar 21, 2020, 8:45 PM UTC

ammarahmed6506 wrote: post #6

jitl wrote: post #3

I’m surprised to not find any iteration or query primitives. No key scanning?

MMKV is a simple key-value store but the good thing is that it is fast, A custom indexer can be made for querying. However there is a method to get all the keys in the storage but its not exposed in react native side. Is that what you mean?

I couldn’t find any numbers or benchmarks in the repo. What did I miss?

Re: Show HN: Fast database for React Native with multiple data-type support

#10

Post by sercand » Sat, Mar 21, 2020, 9:40 PM UTC

We are using SQLite on React Native with the JSI without writing a java or object C bridge. As a result, all operations are much faster and almost all of them don't need to Promise callback. I don't see any reason to use this over SQLite. We can do same thing on SQLite much faster way.