MAmarcuslager·Jul 16, 2017
You wouldn't mind me using your data?
I've seen Bubblehunt and I've played aound a little bit with it. Reach me at github.com/kreeben/resin.
In Show HN: Fastest search engine in the worldkreeben
resin
C#2016–2025
kreeben / resin
resin
Language model search engine built on a vector database and an anything key/value store.
Data & DatabasesAI & Machine LearningLearning & ReferenceSearch & Information RetrievalLibraries & SDKs
6Distinct people
41Mentions
0Explicit recommenders
578GitHub stars
What to know before exploring
What it is
Language model search engine built on a vector database and an anything key/value store.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:59:22 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year41 dated mentions
Observed mentions: 2016-03-14 11:29:50 UTC to 2025-12-16 14:02:05 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 21 | 17 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 10 | 8 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 2 | 0 |
What Hacker News says
21 sourcesShow HN: Fastest search engine in the world
Hi! According to my benchmark tests I've just built the fastest free-text search engine in the world [0]. However, providing proof of that as well as making people care has proven to be a near impossible task. I could use some help from fellow programmers to both work on the formal proof but also to test this code against the Big5's offerings of full-text search.
Would you care to go fetch an amount of common crawl data to test the abilities of ResinDB?
If not, then do you perhaps have another strategy to convince people when you have invented something big? Is writing papers and formally proving things a way into the market place? If so, how do you figure MongoDB overthrew it's previous market place ruler? It had no formal proof of anything. The market loved it though, for it's speed.
I would love for formal proof to be a success indicat
Read the rest
or. Diverting people from using Lucene/Elasticsearch would then be a breeze.
Why ResinDB? Because why use a cloud-based luxury cruiser when the most precise relevance, the fastest querying and most energy-aware choice is provided by using an on-premise kayaak. ResinDB on-premise, a word2vec search engine implementation, is the fastest (local) information retrieval system known to me. How about men?
[0] https://github.com/kreeben/resin
Embedded SSD-based database with concurrent read/write
3 points · Open discussionShow HN: DocumentTable – a specialized file for document db operations
2 points · Open discussionA latch-free MVCC document database/search library
2 points · Open discussionHow can a indie dev keep pace with big five? [pdf]
1 points · Open discussionShow HN: Home-made database with log-structured writes
Hi, I'm Marcus. I've spent the last 15 months or so home-coding on a document database, after work, on weekends (every waking hour). My plans for this particular weekend was to implement log-structured writing. It went faster than I thought and the results were faster querying times and fast, append-only writes.
I've been working on this for almost a decade and being this close to the finish line feels surreal. This is my seventh iteration I believe. Everytime I realized I had an architecture built on a bad model I walked away, often in fury, depressed over my weak coding abilities but bouncing back pretty quick. I've gotten to a place where I'm comfortable throwing away months and months of coding. When starting anew I always did it fresh.
I did this from love and facination of search and NLP and to get good at coding. I started late in
Read the rest
life as a professional programmer and have always felt the need to catch up with those younger than me. Today I feel like I achieved something.
Here is a demo of a search engine [0] built on ResinDB [1]:
[0] http://searchpanels.com/
[1] https://github.com/kreeben/resin/
Show HN: Vector space/tf-idf bag-of-words implementation
2 points · Open discussionPortable index for storage engines
1 points · Open discussionShow HN: Document db with word2vec-driven scoring and Levenshtein automata
2 points · Open discussionSearch is not hard. Microsoft are being lazy. Which is good for me. I'm building what I thought was a Elasticsearch killer. Seems it's also a DocumentDB killer. Search is first-class with Resin: https://github.com/kreeben/resin
In Azure Cosmos DB, a globally distributed databaseHi, this is what I would like the dotnet core community * to start using instead of looking for the Lucene team to port several years old java code to core. We already have a search engine on dotnet core. It's called Resin. I'm only a few minor optimizations away, plus one or two features I'd also like to include, from having a robust and full-featured Lucene replacement, leaner, faster, with better compression and with readable code (sometimes even object-oriented). Time to bury Lucene.Net people. Come help out.
*) Is there such a thing? I mean, you're awfully quiet and compared to the java community, which I know exists, you seldom help out in open-source projects. What's up with that? Haven't found the right project yet? Search, i.e. information retieval and NLP, is about as about as interesting as it gets, at least to me. General AI w
Read the rest
ill be bourne out of IR and natural language processing. Not interested yet? There's a really cool Trie and some pretty sweet tree traversing algorithms that can perhaps be optimized. Have a look at my poor-mans [Levenshtein automaton over in-memory trie](https://github.com/kreeben/resin/blob/master/src/ResinCore/I...) and the same [over a disk-based trie](https://github.com/kreeben/resin/blob/master/src/ResinCore/I...). Sentiment analysis comes later on. It's great fun!
Show HN: Auto-indexing key-value store
14 points · Open discussionShow HN: Fastest search engine on dotnet core
2 points · Open discussionVery interesting model that suffers from a couple of things that other data structures solve better IMO. One thing that I don't understand and I guess I have to go back and read the article again, is how the distance from any node X to the arbitrarily selected root M tells me anything about the distance between X and the query term Q. If I live in London and the distance from me to Paris is 50.000 km, and you live in Rome, 70.000 km from Paris, that does not give me enough to calculate the distance between Rome and London.
IMO there is no data structure better suited for a search tree than the doubly-chained character trie [0], as it has the following features:
- small in memory (every word is stored once at the most, but more often less than once)
- traversing and doing exact matching allow you to prune half of the tree at every step
- r
Read the rest
equires you to calculate the distance only at querying time, not when constructing the tree
- apart from exact and fuzzy matches also support prefix matches (traverse up to the path of the prefix, return all children that are EndOfWords)
- can be represented on disk in a way that makes reading insignificantly slower than reading from memory
- if nodes are lexically sorted when tree is constructed, you have also pretty much solved range queries
[0] https://github.com/kreeben/resin/blob/master/src/Resin/IO/Lc...
The trie is to be the perfect tool for when you find yourself combatting big data. What you find out eventually about all of the cloud offerings from all of the big players that claim they will solve both storing and map/reducing over your data is that you can do the same thing on your laptop, for cheap money, as long as the data is represented in a compressed form that still allow for querying. The trie is a zip file and a search engine in one.
Edit: formatting and clarification
Showing the 15 most recent of 21 sources. Enable JavaScript to search and browse every indexed mention.