Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish to Hex #429

Open
lpil opened this issue Jan 18, 2024 · 5 comments
Open

Publish to Hex #429

lpil opened this issue Jan 18, 2024 · 5 comments

Comments

@lpil
Copy link

lpil commented Jan 18, 2024

Hello there! This is a really cool project, thank you!

I'd like to try this out with some applications. I notice the version on Hex is now quite old: 0.9.4 from December 2018. Would it be possible to get the latest release pushed to Hex? https://hex.pm/packages/leveled

Thank you,
Louis

@martinsumner
Copy link
Owner

Thanks Louis. I'm planning to tag some new releases early next week, so will get the hex stuff done then.

P.S. I've been reading the gleam tutorial recently, an exciting project. I've also being doing some experiments with thoas to replace our use of mochijson2 in Riak. So thank-you!

@lpil
Copy link
Author

lpil commented Jan 18, 2024

Thanks for the quick reply and the kind words. :) Looking forward to the release!

My goal is to find some time to make a embedded database library for Gleam that one might use in place of SQLite, as compiling that C is annoying and it can't be used from an escript. Leveled seems like it could be a good starting point in my exploration of that space.

There seems to be a small performance regression in Thoas at the moment. I'm not sure how that happened, I need to bisect it and benchmark against Jason to see what the issue is. Seemly no users have noticed a difference, but Thoas no longer quite matches Jason in the benchmarks.

@martinsumner
Copy link
Owner

A warning, Leveled is very efficient in the context of Riak, but that efficiency may not transfer to a general use case.

In Riak the objects tend to be quite large i.e 2KB to 2MB. A lot of the time the object's metadata is required but not the whole object (as the object is stored in three different databases within the cluster, we pull the version vector from the metadata from each location, but normally the object body from just the one place). This meant that levelved, which stores the object value outside the LSM tree, and allows the metadata to be fetched directly from the LSM tree, was more efficient than C++ alternatives like leveldb which take a big hit in terms of write amplification by keeping the value with the key within the LSM tree.

So if you have small values (where write amplification would not be such an issue), or never have need for metadata without the value - it is likely to be out-gunned by alternatives.

There are some also idiosyncrasies in the project that reflect its legacy as a personal project (and my first one in Erlang). My apologies in advance.

If you have a play, and end up with a bunch of questions, happy to have a call to see if I can help.

@lpil
Copy link
Author

lpil commented Jan 18, 2024

Thank you, I'll keep that in mind if I ever find the time to explore this project. 😁

it is likely to be out-gunned by alternatives.

Unfortunately there's not much in the way of alternatives if you want to stay in pure Erlang, so you have that advantage!

@martinsumner
Copy link
Owner

Try this - https://hex.pm/packages/leveled/1.1.0-hex

I think this should work, but I had a bit of trouble with the deps not being on hex with the right version, so may well have made some rookie mistakes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants