danielmewes

9 ms·

31.
by danielmewes 11y ago
Daniel @ RethinkDB here. We're going to ship an official Java driver very soon. We decided to focus on a small number of core drivers first while the protocol and query language were still undergoing rapid extension. Now that the proto
32.
by danielmewes 11y ago
It's not currently on our road map. Even though there are some well-researched algorithms for it, actually implementing transactions in a distributed system is pretty hard. It also comes at significant performance costs, which would in
33.
by danielmewes 11y ago
Two 1 GBit ethernet ports, one used for intra-cluster and one for client connections.
34.
by danielmewes 11y ago
As a second data point: I tried table.groupBy(function (x) { ... }).count() where the function maps the documents into one out of 32 groups (so that's less than your 94, but shouldn't make a giant difference... I just had
35.
by danielmewes 11y ago
Thanks for the info. I'll look into this. The fact that we are running out of memory suggests that we're doing something wrong for this query.
36.
by danielmewes 11y ago
Daniel @ RethinkDB here. We'll release the details shortly. This was running on 12 core Xeon servers with 2 SSDs each in software RAID 0. There were also additional read queries running at the same time as the write queries, and the re
37.
by danielmewes 11y ago
We did a couple of scalability improvements in 2.0, but didn't optimize groups and counts specifically. Would you mind writing me an email with your query or opening an issue at https://github.com/rethinkdb/rethink
38.
by danielmewes 11y ago
Understood. We're planning to test with Jepsen soon. This will happen once we have implemented fully automatic failover (at the moment it still requires manual intervention, even though it's usually straight forward). We have a fi
39.
by danielmewes 11y ago
Daniel @ RethinkDB here. As you mention, RethinkDB is fully open source so RethinkDB is always going to remain freely available.
40.
by danielmewes 12y ago
Uncertain. The issue is still in the planning phase. We'll only remove range sharding if we're confident that hash-based sharding provides an adequate replacement of course. It's possible we'll keep both.
41.
by danielmewes 12y ago
We'll start developing one pretty soon. You can follow the progress at https://github.com/rethinkdb/rethinkdb/issues/3930
42.
by danielmewes 12y ago
We currently support range sharding by primary key. Both compression and custom sharding are things we definitely want to do ( https://github.com/rethinkdb/rethinkdb/issues/1862 , possibly https://g
43.
by danielmewes 12y ago
Not sure if we will have benchmarks available at launch, but they should follow soon after.
44.
by danielmewes 12y ago
Great to hear! Let us know if you run into an issues or have questions.
45.
by danielmewes 12y ago
Daniel @ RethinkDB here We're still optimizing the performance of certain operations. There are definitely still a few rough edges, especially with analytical queries as you'd pointed out. As far as basic operations (inserts, upda
46.
by danielmewes 12y ago
We're generally open for this. However it's a bit of extra work since RethinkDB doesn't currently have a pluggable storage backend API like MongoDB or MySQL do.
47.
by danielmewes 12y ago
How many users are you expecting? If you go over a couple 1,000 active changefeeds in 1.16, I recommend setting the `maxBatchSeconds` optional argument to `run` to something like 10 (the default is 0.5). That change should significantly red
48.
by danielmewes 12y ago
RethinkDB 1.16 doesn't have auto-failover yet, but ReQL admin still helps because you can integrate it with external cluster management tools that you could use to initiate the failover. We are actively developing the foundations for i
49.
by danielmewes 12y ago
Changefeeds are currently bound to a database connection, so they will get terminated if for example the application server goes down or there's a networking issue. We feel like for many queries (especially the ones you find in web app
50.
by danielmewes 12y ago
This document explains our basic replication architecture and might be helpful http://www.rethinkdb.com/docs/architecture/ Let me know if you want to know more about a specific aspect.
51.
by danielmewes 12y ago
Hi Chris, great question. There are a couple of advantages actually. - You don't have to write logic to figure out which clients need to be updated with some data. You just run the queries that you need to to generate the data for th
52.
by danielmewes 12y ago
Have you tried http://php-rql.dnsalias.net/ ? It's pretty much equivalent to the official drivers, and well maintained (usually gets updated within a week after new RethinkDB releases).
53.
by danielmewes 12y ago
Nothing special. We use S2 to compute a covering of a polygon (like a town) by a number of grid cells. If you insert a polygon (or line) into a geospatial index, it will actually be inserted multiple times, with one entry for each grid cell
54.
by danielmewes 12y ago
Hi cwmma. RethinkDB actually does use Hilbert curves at multiple scales for indexing geometry. The implementation for this mapping comes from Google's S2 library. You can find the details documented in Google's code: https:/
55.
by danielmewes 12y ago
Ok, got it. Guess I mis-represented what WGS84 in my earlier post. What I should have said is that in RethinkDB we only mean a specific reference ellipsoid for computing distances between latitude/longitude coordinate pairs when referr
56.
by danielmewes 12y ago
> The implementation is based on the S2 library ( https://code.google.com/p/s2-geometry-library/ ) also used by PostGIS, which AFAIK does spherical linear interpolation. Note that RethinkDB actually doesn't
57.
by danielmewes 12y ago
> Also, does this support many projections, or just a few. RethinkDB doesn't do any planar projections of spherical coordinates (if that's what you are asking for). There are many independent tools available to perform such pro