That is a problem in systems that expect the tenant_id to always be in the query, so you can locate which node the query needs to go to.
1,954 karma · joined October 30, 2007
Founder of pganalyze - Postgres performance at any scale.
Feel free to drop me an email: lukas@fittl.com
[ my public key: https://keybase.io/lukasfittl; my proof: https://keybase.io/lukasfittl/sigs/rqDeEWdp4ktJubli4QY0dNaUJ6K-pdpDTHCFOi9v7WU ]
That is a problem in systems that expect the tenant_id to always be in the query, so you can locate which node the query needs to go to.
You could probably do it nonetheless with Rails' own has_many/belongs_to relationships for that sub-tenant, but the automatic adding of department_id into queries wouldn't happen.
Depending on what storage you end up using, that might matter or not. For example with Citus, you'd typically take the top-level tenant (customer_id) as a shard key, and just have all the departments of that tenant on the same node - so it would work fine.
Since Rails isn't used to include something like a tenant_id, and doesn't support composite primary keys either, you'd have to always hand-write your SQL.
Feel free to take a look at the source - it effectively ends up being a default scope with some additional glue code.
I've been working on this library for 2-3 months now, if somebody gives it a try let me know how it goes :)
I'd be happy to answer any questions as well.
Feel free to shoot me an email at lukas@fittl.com - happy to share notes and code.
In particular this one: https://github.com/zfsonlinux/zfs/issues/3645
I think you could look into doing an EB1 green-card in the extraordinary ability category - the requirements are similar to the O-1 (just reviewed a bit more thoroughly), and it'd give your wife a work permit if you file the paperwork together. In theory that process can be done in ~3 months (for the EAD card, which would allow her to work) when you file the I-140 with premium processing.
See also https://www.uscis.gov/working-united-states/permanent-worker...
Curious since I'm currently researching how PostgreSQL could do better in this space :)
https://blog.cloudflare.com/scaling-out-postgresql-for-cloud...
To load or append data into a cstore table, you have two options:
You can use the COPY command to load or append data from a file, a program, or STDIN.
You can use the INSERT INTO cstore_table SELECT ... syntax to load or append data from another table.
Note: We currently don't support updating table using DELETE, and UPDATE commands. We also don't support single row inserts.
So I think you can certainly mutate tables, but the focus is on bulk-inserts, rather than individual append actions.Some Postgres committers work on Citus as well (e.g. Andres Freud), so I'm sure this has been thought through before.
This would be complimentary to what Citus does, which is distributing the load across multiple shard instances (each with their own cores, benefiting from the parallel work in 9.6).
Inside the Docker (or rkt) containers you can run whichever distribution or static binary you like.
The combination of CoreOS+Kubernetes+Docker+Alpine Linux (inside the containers) works pretty well in my experience.
https://github.com/FormidableLabs/victory seems most promising, but isn't really d3, more "d3-like".
Any lessons learned / things one should watch out for? (specifically around required evidence or RFEs that you got issued)
Thanks for your time! :)
I'll certainly revisit Influx once tsm1 is the default and backups are in :)
Re 0.8: As the other poster noted, I think it was related to histograms and/or derivatives - would have to go back to look.
I really, really wish they'd hire 2-3 more database engineers to focus on the actual timeseries database, not nice looking tooling around it.
Simple things like incremental backups are still not working as expected in recent releases. Useful features from the 0.8 series still haven't been ported. And tsm1 is a neverending effort it seems.
We've went back to Postgres for storing timeseries data since we didn't feel confident to use InfluxDB in production.
In my head I compare Vienna with London and the US (SF/NYC/etc) which are 2-3x as expensive, plus healthcare is worse.
I'm from there, but part of the reason why I keep coming back is cause its affordable to rent, even in the hip districts (600-700 EUR for 1br) + a great city to live + good bunch of startups + cheap for flying in/out. Prague is similar.
Also heard great things about Sofia, but haven't lived there (yet). And Berlin is of course a good option as well.
Its cool because:
We visualise the metrics & counters that are usually hidden away in PostgreSQL internal tables.
Plus we check that your database is fast and configured correctly.
Also: I'm a techie with a UX hat, and data visualisation and pattern matching is fun :)
Why Arabic Is Terrific http://idlewords.com/2011/08/why_arabic_is_terrific.htm
Yeah - I'm not 100% happy with it either. Initially I had Exploration, which is really what I mean (you open up the floodgates and look quickly at a lot of different ideas, before zooming in on one).
But that sounded kind of quirky/confusing when used for comparing it with Execution, as in Execution vs Exploration.
And after all, Ideation is also a valid word to use in this context.
This was a big problem/mistake we made back then (and which isn't obvious from the slides) - we just didn't let people try the product, since we didn't want to be a hosting company ourselves.
We did show demos to people and did pilots in a few cases, but it would have benefited us a lot to have a public installation where people could have tried out the product.
I'm sorry we didn't get to work together then - there was certainly a lot of interest that we managed (and filtered through) poorly.
Luckily I've learned from that (I hope!) :)
Direct PDF link: http://www.seedcamp.com/main/wp-content/uploads/2011/09/Seed...
https://vimeo.com/15091562#at=0 (also by a dad with his son)
Started with 10k GBP some months ago (to bootstrap fulltime) and keeps a spreadsheet of all expenses and income.
Also a lot of good marketing/copywriting advice and feedback that you'd otherwise not get.
Whether you'd like to spend the money is another question of course.