Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
bluestreak
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
31.
▲
Show HN: Query live crypto trades with SQL in real-time
(questdb.io)
1 points
by
bluestreak
5y ago
|
0 comments
32.
▲
We Built a SIMD JIT Compiler for SQL in QuestDB
(questdb.io)
16 points
by
bluestreak
5y ago
|
0 comments
33.
▲
by
bluestreak
5y ago
Questdb's author here. I do share Ayende's sentiment. There are things that the OP paper doesn't mention, which can help mitigate some of the disadvantages: - single-threaded calls to 'fallocate' will help avoiding
34.
▲
by
bluestreak
5y ago
There is an option to park threads, publisher can signal the consumer if needed. This model is non-blocking to allow applications to have fewer thread and those threads to process more than one queue or more generally do more than one task.
35.
▲
QuestDB snares $12M Series A with hosted version coming soon
(techcrunch.com)
1 points
by
bluestreak
5y ago
|
0 comments
36.
▲
by
bluestreak
5y ago
Hello HN, We previously shared benchmark results showing write speeds of 1.4 million rows per second [1] and how we built this ingestion system. Over the last few months, we've developed functionality that supports geospatial data in o
37.
▲
Show HN: Demo geospatial and timeseries queries on 250k unique devices
(questdb.io)
7 points
by
bluestreak
5y ago
|
1 comments
38.
▲
The SO_LINGER page, or: why is my TCP not reliable (2009)
(blog.netherlabs.nl)
68 points
by
bluestreak
5y ago
|
8 comments
39.
▲
by
bluestreak
5y ago
I have not had any experience with these trees, but I will try to read and make sense of this paper, thanks! There is C++ implementation here is someone else is interested: https://github.com/rahulyesantharao/b-epsilon-
40.
▲
by
bluestreak
5y ago
Reading data via index would lead to scattered memory reads on actual data, which is a dead-end from an optimisation standpoint unfortunately. Using index would have been much simpler but also slower.
41.
▲
by
bluestreak
5y ago
Query performance would be affected in so far as ingest jobs share the same thread pool as query jobs. As I am writing this I am also realising that perhaps we should have an option to separate these jobs... If we ignore resource usage and
42.
▲
by
bluestreak
5y ago
Thank you! We are not yet distributed. That’s coming right up along with Jensen style tests. We are really serious about testing!
43.
▲
by
bluestreak
5y ago
We launched QuestDB last summer [1, 2]. Our storage model is vector-based and append-only. This meant that all incoming data had to arrive in the correct time order. This worked well for some use cases but we increasingly saw real-world cas
44.
▲
Building a new vector based storage model
(questdb.slab.com)
80 points
by
bluestreak
5y ago
|
9 comments
45.
▲
Building a new vector-based storage model
(questdb.io)
2 points
by
bluestreak
5y ago
|
0 comments
46.
▲
Building a garbage-free network stack for Kafka streams
(questdb.io)
3 points
by
bluestreak
6y ago
|
0 comments
47.
▲
by
bluestreak
6y ago
this would persist kafka traffic to database to make it available long term and at high speed :)
48.
▲
by
bluestreak
6y ago
are there plans to support Kafak connector API, specifically PostgreSQL?
49.
▲
by
bluestreak
6y ago
This formula breaks down when you have a kids that go to school and worse still, two separate schools. Not everyone can hop on a bike.
50.
▲
by
bluestreak
6y ago
It is a good question. I feel there is a happy medium where boilerplate is in Java and more intricate data processing routines are in C++. Makes both worlds simpler. I like C++ better. Those things you mentioned - Java truly sucks at indeed
51.
▲
NYC taxi meter and options pricing
(questdb.io)
125 points
by
bluestreak
6y ago
|
56 comments
52.
▲
by
bluestreak
6y ago
This ran on Java 11. This isn't so much of an issue for us. We are trying to avoid allocations, even as trivial as those. There are other examples that allocated where they should not, for example this lambda will allocate. () ->
53.
▲
by
bluestreak
6y ago
here is one: https://github.com/questdb/questdb . Disclaimer, I work on this project. Main reason we use Java is speed of development (which increased with amount of base libraries written) and ease of testing.
54.
▲
by
bluestreak
6y ago
We have written a database in zero GC java and one thing I have not seen any evidence of "escape analysis". @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class Esc
55.
▲
by
bluestreak
6y ago
QuestDB | Technical Content Writer | Full Time | London,UK or Remote At QuestDB we help developers handle explosive amounts of data while getting them started in just a few minutes with the simplest and most accessible time series database.
56.
▲
by
bluestreak
6y ago
Hi HN, Author here. QuestDB is a fast SQL open source database for time series. About a month ago we launched on HackerNews [1]. Today, I am excited to announce QuestDB 5.0.3 [2]. This new release includes our changes in memory mapping stra
57.
▲
Re-examining our approach to memory mapping
(questdb.io)
3 points
by
bluestreak
6y ago
|
2 comments
58.
▲
by
bluestreak
6y ago
Hi HN, Author here. QuestDB is a fast SQL open source database for time series. About a month ago we launched on HackerNews [1]. Today, I am excited to announce QuestDB 5.0.3 [2]. This new release includes our changes in memory mapping stra
59.
▲
Why we changed our approach to memory mapping at QuestDB (YC S20)
(questdb.io)
1 points
by
bluestreak
6y ago
|
1 comments
60.
▲
by
bluestreak
6y ago
Thanks for the explanation Nikita. Any branching, hashing etc will increase execution time. The execution example is on laptop, which has 2 memory channels. 0.13s is absolute max that this laptop is able to muster as far as memory throughpu
More ›