ObjectBox: Fast object-oriented database for Go | Hacker News Reader

ObjectBox: Fast object-oriented database for Go

github.com

129 pointsthomaslewis41 comments

I don't like how it's a closed source binary that's downloaded as part of the install process. Realm used to be like this too, but they open sourced their core later, I wonder if ObjectBox has similar plans.

Looks like it

https://objectbox.io/faq/

" We will open source more components later, but first we need to figure out some things with ObjectBox. Please give us time on this. We’re currently putting all our efforts in advancing the product. Please contact us if you have questions about this (email contact [at] objectbox.io.). Thank you."

Seems disengenuis to host on github and post here.

The docs are so light on details. The example code is weak. The website doesn’t share any examples on how this is used.

Do you refer to https://golang.objectbox.io ? Check https://docs.objectbox.io/ for what is available for Java.

Are you affiliated with ObjectBox?

https://github.com/greenrobot

A bit off-topic but it's interesting to see the name greenrobot pop up again after all these years. :)

Early Android developers may remember greenrobot/greenDAO and greenrobot/EventBus libraries from back in the day, both very helpful at the time.

Good old days... :)

How does this compare to, say, Versant OODBMS ?

Not sure if Versant supports Go. Anybody knows Versant's pricing? Don't think they come for free.

Definitely not free and definitely no support for go. I was actually wondering how objectbox compares to versant but I quickly answered myself: objectbox is designed for low-end loads and iot stuff while versant is more geared towards big databases (ie millions of objects) and concurrent, networked access.

Anyone willing to correct me or add to this is welcome (and please do).

> ObjectBox object oriented database - up to 10x faster than SQLite

How does it achieve this?

Most likely by not providing data safety and a bunch of features. The classic example with databases is that the super fast ones will report your writes are finished even before the database starts thinking about writing the data to disk, not to mention flushing it.

According to this comment[0], it is ACID-compliant. What other data safety features are you thinking might be sacrificed?

0: https://news.ycombinator.com/item?id=18569031

More info on ACID & transactions here: https://golang.objectbox.io/transactions

Based on safety research [1][2] I’ve read on numerous databases, I’ve learned that there is almost always a big difference between vendor promises and reality. Thus when reading claims of order of magnitude performance gains against one of the most well tested databases in the world, I lean towards the assumption that the gains are due to shortcomings, whether intentional or not.

—

[1] https://aphyr.com/tags/jepsen

[2] https://jepsen.io

Does this use the FS or is it purely in memory?

I've got GBs of CSV data that I'm managing manually and due to response times, need solutions that reduce wire trips. This means that traditional databases have proven difficult due to the distance between process and DB. Something designed for local usage (SQLite/etc) is an area I want to research, so ObjectBox sounds interesting on that front as well. Though, it looks like its goals are mainly IoT, so I'm not too hopeful on this front.

SQLite is pretty bulletproof and tested in this area. Lots of examples for your project to take advantage of, and very high performance for in-memory data sets.

SQLite is a very nice embedded DB indeed. If you like SQL. ObjectBox enables you to work with Go structs and gives you additional performance.

It's ACID compliant, and thus not not in-memory. https://golang.objectbox.io/faq covers that in detail. In the FAQ, there is a section on comparing to JSON; I guess the same would hold true for CSV.

PS.: Wouldn't worry about a label saying "IoT" if the technology fits your need.

I have used SQLite databases sharded at 2GB due to mobile fs limitations, storing 10-14GB in total, total lookup times across whole query was still on the order of 100ms untuned, unoptimized.

SQLite has your back.

I've been using clickhouse (https://clickhouse.yandex) a lot recently. One thing I found useful was that the underlying tables are just folders on disk that you can easily copy around. The data will be automatically compressed too.

I'm sure it'll depend on some of your other constraints, but may be worth looking at. I've been extremely impressed with its performance.

How did you find clickhouse vs drill/dremio? Have you tried maybe both and compared them?

I'm afraid I've not tried those, I played around only a bit and mostly spent a while trying to get cassandra setup but failed.

Then I hit on https://tech.marksblogg.com/benchmarks.html and saw clickhouse sitting at a very impressive point given the hardware it's on there. It was one of the few data things I saw that looked like it scaled down to a level relevant for me (cassandra I think talks about a dev setup of 5 servers). It's been fast enough with zero tuning or work so far that I've not done that much. I'm sure I could get closer to its speed by carefully setting some things in postgres, or clever work somewhere but I've got other things to do and that's not my speciality.

It has a few issues with ingesting CSV (I end up quoting everything, though I think it's less hassle if you use TSV instead).

Frankly, it's been incredible for my analysis work. apt-get install setup, fast to ingest data, easy to query and output large amounts of things. Happily works on a single box, though apparently scales up as well. More than happy to waffle on about this but I'm aware I've gone on very long already for a "I don't know" answer.

Are there any benchmarks that show how fast this db is?

The Go release post (https://objectbox.io/go-objectbox-golang/) has some numbers. "On a i7-8850H CPU, ObjectBox consistently processes over 1.5 million CRUD operations per second with 4.4 million object reads per second."

There's some general info here, including a comparison to SQLite: https://objectbox.io/dev-get-started/

For Android, there's even a repository to test it yourself: https://github.com/objectbox/objectbox-performance

Comparing a RDBMS with an object database is pretty useless for benchmarking.

I'd be more interested to see comparison to, for example, Realm[1].

[1] https://en.wikipedia.org/wiki/Realm_(database)

There's a open source benchmark here: https://github.com/objectbox/objectbox-performance - last time I checked ObjectBox was several times faster than Realm.

I only see Java source code here. Is ObjectBox Java the same database code as ObjectBox Go?

EDIT: I see the 'objectbox-go' repo has a separate set of perf tests, but only for ObjectBox Go -- not either of the unnamed "NoSQL" competitors, nor for SQLite.

The initial question was about Realm, thus the link to Java. The core of ObjectBox is the same on every platform (C/C++ for maximum speed). We haven't finished the other benchmarks yet. Sorry for teasing with those. We'll be done with those soon and they will be open source.

Is this something like couchdb/couchbase?

Not really, ObjectBox is an object DB and emphasizes performance (no JSON but FlatBuffers for example).

If this uses os.File.Sync, it's not safe on MacOS.

Also it would benchmark artificially fast on MacOS.

https://github.com/golang/go/issues/26650

Many storage libraries are affected, including Bleve.

Interesting. ObjectBox does NOT use os.File.Sync. This stuff is done by a low-level C layer. We'll verify next week, thank you!

The method used in the fix to the bug above is easy to apply in C.

I serialize into grpc and dump into badger.. excellent performance, no cgo kludge

You probably don't do a lot of queries? Badger is a K/V store and has no knowledge about the value. Thus querying sucks and if you want indexing, you are on your own. Relations? Anyway, for simple caching that's probably fine.

What does 'object oriented' database mean? A relational database is already an interface to data. Is it just storing serialized binary data with a key?

The FAQ covers this: https://golang.objectbox.io/faq#how-is-objectbox-different-f...

“Fast”, “database” and “Go” are three of the scariest words to put together when viewed thru SRE eyeballs...

Reply on news.ycombinator.com