TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Sophia – An embeddable key-value database

134 点作者 isaacb超过 11 年前

21 条评论

rgbrgb超过 11 年前
I know it seems superficial but beautiful docs are one of my most trusted heuristics when I'm considering using a library. If the author cares about the aesthetics of the docs, it often means they care about the aesthetics of the code, which really does matter a lot. We can make ugly things or we can make beautiful things. I really respect people who take the time to make beautiful tools.
评论 #6396967 未加载
评论 #6397098 未加载
saurik超过 11 年前
Anyone know anything about how this compares in practice to Lightning MDB (which uses a memory mapped B-tree, I think, and is apparently insanely faster than most of the other enbedded key-value stores people normally examine)?
评论 #6398469 未加载
评论 #6398060 未加载
apendleton超过 11 年前
Having just gone through the exercise of picking an embedded key-value store for a project, some things that would be nice: how does it compare to other things besides leveldb (which, to be frank, isn't a stellar performer)? In particular, how does it compare to Tokyo/Kyoto Cabinet, Lightning MDB, or Sqlite4's LSM? Does it support data compression (either with a single pre-selected algorithm like LevelDB and Snappy, or in pluggable fashion like LSM)? How does it deal with concurrent access by multiple processes?
评论 #6398064 未加载
clumsysmurf超过 11 年前
For Java &#x2F; Android, I&#x27;ve been using H2&#x27;s MVStore, which is log structured and uses counted B+-trees. It&#x27;s nice not having to go through JNI for good performance in Java.<p><a href="http://www.h2database.com/html/mvstore.html" rel="nofollow">http:&#x2F;&#x2F;www.h2database.com&#x2F;html&#x2F;mvstore.html</a>
评论 #6397227 未加载
评论 #6398621 未加载
dfischer超过 11 年前
Typography is hard to read.
评论 #6396926 未加载
i_have_to_speak超过 11 年前
Cute website. Some random thoughts:<p>Concurrency:<p>- No mention of it. There appear to be spin locks in the source. No multi-threaded tests.<p>Stability and data safety:<p>- Github has 2 days of history, and 4kLoC of test code. Why should I trust my data to you?<p>&quot;high load environment&quot;:<p>- So what exactly does it do in a &quot;high load environment&quot;? How do you define &quot;high load&quot; in the first place? CPU load? I&#x2F;O load from other processes? What shortcomings of the competition under a &quot;high load environment&quot; are you trying overcome?<p>Backup:<p>- How do I do hot backup?<p>Benchmark:<p>- LevelDB is not a fair comparison as it offers additional non-trivial functionality (snapshots) that cannot be built up on top of Sophia. LevelDB APIs are also safe for concurrent use, which adds overhead. Kyoto Cabinet would have been more suitable as a peer to benchmark with.<p>- 3 million records with 16-byte keys and 100-byte values is not really an interesting benchmark dataset.<p>- Iteration over a static database is not interesting, either. Is there any alternative other than locking an entire mutating database for the duration of iteration?
pwpwp超过 11 年前
I, for one, wouldn&#x27;t trust my data to a library by somebody who uses the same text decoration for hyperlinks as for plain text.
评论 #6398699 未加载
oscargrouch超过 11 年前
Really guys, can you give more constructive or at least more (not based in bullshit assumptions) comments? if not, just shut up..<p>This is a non-trivial effort, and all people do is to complain about the font face or if the punctuation was right?<p>First, in the benchmarks it just crush leveldb, this is already by itself a great achievement. can you confront the benchmarks? you do it one yourself with a different configuration? no?<p>Second, if you are not a database expert and can create proper critics (constructive or not), just keep it to yourself.. i wonder how so many people get up with all of this conclusions so fast, without a proper look at the source code and to have a reasonable amount of time to know what are they talking about.<p>its very hard to create things like this, but very easy to critisize without any background.. dont forget about it<p>if you have something to say about a small thing, that do not have a direct relation to the product or thing itself, if theres already one comment about it, that enough! do not spam, answering it, or creating new comments about it, this is just so rude and unrespectful..<p>really, things are getting creepy on HN.. and its not only in this thread
评论 #6402145 未加载
Negitivefrags超过 11 年前
It says that the benchmark source is on github, but I can&#x27;t find it.<p>It doesn&#x27;t appear to be in their primary repo.<p>I would like to try and do my own test against another embedded data store like Berkeley DB but I want to know more about the conditions on the test. How many threads were used, that kind of thing.
评论 #6397302 未加载
Goopplesoft超过 11 年前
Very cool. As a suggestion, increase the link size under the main title, wasn&#x27;t clear to me what the next step was at first after reading the introduction text.
laichzeit0超过 11 年前
In case any of the devs read this:<p>1. Can multiple processes use the same database concurrently? (Separate address space processes, not fork()&#x27;d)<p>2. Have you tested this with uClib&#x2F;cross compiler? (I would like to use it on a MIPs embedded router)<p>The reason I ask this is because I recently had the displeasure of having to hack a non-volatile RAM library to work with shared memory &#x2F; thread safe and something small like this would be a perfect replacement with a lot less pain.
dkhenry超过 11 年前
Was this man&#x27;s computer use being charged by the key stroke? I mean I understand using a few abbreviations here and there, but i.c ? At least name your files descriptively.<p>I would avoid using this for realzies if only for the fact that if something broke trying to fix it in that code base would be prohibitive
hosay123超过 11 年前
Looks nice, but note this doesn&#x27;t appear to support consistent reads (unlike LevelDB snapshots)
conductor超过 11 年前
I love the simplicity of the site and the C code. I will definitely use it, thank you.
MichaelGG超过 11 年前
I&#x27;ve got a need for something like this, but would like to have the keys and values delta encoded to achieve simple, yet effective, compression.
评论 #6398878 未加载
acron0超过 11 年前
Had a quick, 30 min bash at a win32 port using msinttypes and pthread-win32 but no luck yet :( Would love to see one though...
ksec超过 11 年前
Something for Mozilla to consider using inside Firefox inplace of LevelDB ( If that was ever landed )
buster超过 11 年前
I&#x27;d be far more interested in benchmarks versus BDB (and maybe even sqlite).
maaku超过 11 年前
Snapshots? I could find it in the documentation..
jgalt212超过 11 年前
any word on support for unicode keys?
评论 #6398059 未加载
luisbebop超过 11 年前
Awesome work, congratulations!