Are you talking about the 2008 financial crisis? or do you mean something else?
51 karma · joined January 9, 2019
Are you talking about the 2008 financial crisis? or do you mean something else?
because of this separation, the compute (e.q SQL parsing, etc) can be scaled independently and the storage can also do the same, which for example use AWS S3
so if your SQL query is CPU heavy, then Neon can just add more "compute" nodes while the "storage" cluster remain the same
to me, this is similar to what the usual microservice where you have a API service and DB. the difference is Neon is purposely running DB on top of that structure
also by relying on the whatsapp metadata (the one where you can export by urself), it should be already good enough for feds agent to locate u.
for the E2E itself, as non crypto guy, seems the open whisper paper implemented on whatsapp alr good enough?
1. Make sure the redirect url is a valid harvestapp.com (more checks on state)
2. Encrypt the state since the start of the request, so then they can double check the state hasn't been forged by decrypt and compare
Is there any option beside those?
Or are you saying that we can just create another similar table with only avg_user_session and then join by the dimension key?
In our benchmark, we tried aggregating around 1 billion rows of raw data (2 months data) using count exact distinct -> could achieve around 50-60 seconds. If we use the HLL, the query can be finished around 20-30 seconds.
For the retention part, we're planning to keep it 1 year of data, so around 6 billion rows.
Regarding the 1st point, let say I already have the process implemented in place. If I want to add new common column, is there a better way to easily add new common metrics/dimension without doing backfill?
I've experimented with OLAP engine such as Clickhouse and its view, so far looks good but need a lot of investment upfront to maintain it
I guess the way you mentioned is the only way we can do and we'll try to optimize from that
Cheers!
[0] - https://github.com/checkr/flagr/issues/139#issuecomment-4028...