79816a9715
* test(retention): add http api tests for retention breakdowns
This just adds tests for person and event property breakdowns
* Add helper function for substituting clickhouse sql params
* feat(retention): add support for multiple breakdown props
This just reuses the work done for funnel multiple breakdown values. I
haven't tested this with anything other than person or event properties.
Rather than try to get it working for all the other property types.
The change adds a new `breakdowns` parameter to the retention endpoint,
that is the same as for funnels, e.g. it looks like:
```
{
...
"breakdowns": [{"type": "person", "property": "os"}, ...]
...
}
```
The return structure is the same as the non-breakdown version, except we
also include a `breakdown_values` property that is e.g. `["Chrome",
"95"]`, and the `label` attribute for this case would be "Chrome::95".
* fix typing
* update query snapshots
* remove unused imports
* use `self.assertEqual` instead of `assert`
* Remove explicit should_join_persons
* Revert limit by changes, use breakdown_type
* update snapshots
* fix typing
* use json_encode_request_params in retention test requests
* update json_encode_request_params to encode_get_request_params to better reflect purpose
* perf(retention): add benchmark query for retention with breakdown
* no materialize
|
||
|---|---|---|
| .. | ||
| bin | ||
| materialized_columns | ||
| migrations | ||
| models | ||
| queries | ||
| sql | ||
| test | ||
| views | ||
| __init__.py | ||
| client.py | ||
| demo.py | ||
| errors.py | ||
| generate_local.py | ||
| middleware.py | ||
| README.md | ||
| system_status.py | ||
| timer.py | ||
| util.py | ||
Clickhouse Support (Enterprise Feature)
To accomodate high volume deployments, Posthog can use Clickhouse instead of Postgres. Clickhouse isn't used by default because Postgres is easier to deploy and maintain on smaller instances and on platforms such as Heroku.
Clickhouse Support works by swapping in separate queries and classes in the system for models that are most impacted by high volume usage (ex: events and actions).
Migrations and Models
The django_clickhouse orm is used to manage migrations and models. The ORM is used to mimic the django model and migration structure in the main folder.
Certain migrations (e.g. changing table engines) can be quite expensive and tricky, especially for deployments outside of cloud. To skip these steps during deployment setup, check for the CLICKHOUSE_INITIAL_MIGRATIONS environment variable.
If you need help in making them happen, ask for help from team deployments.
Queries
Queries parallel the queries folder in the main folder however, clickhouse queries are written in SQL and do not utilize the ORM.
Tests
The tests are inherited from the main folder. The Clickhouse query classes are based off BaseQuery so their run function should work just as the Django ORM backed query classes. These classes are called with the paramterized tests declared in the main folder which allows the same suite of tests to be run with different implementations.
Views
Views contain Viewset classes that are not backed by models. Instead the views query Clickhouse tables using SQL. These views match the interface provide by the views in the main folder.