-
Notifications
You must be signed in to change notification settings - Fork 34
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
Comments
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! |
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. |
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. |
Thank you, I'll keep that in mind if I ever find the time to explore this project. 😁
Unfortunately there's not much in the way of alternatives if you want to stay in pure Erlang, so you have that advantage! |
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 |
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
The text was updated successfully, but these errors were encountered: