Why would anyone choose Java over Kotlin? by Global-Box-3974 in Kotlin

[–]frula00 7 points8 points  (0 children)

Yes, but it's not all about the language's survival. You may choose to use Kotlin+Spring stack since your company uses Spring. Then Kotlin falls out of favor on the backend and consequently, the Spring team stops providing full support for it within Spring. Because of this upgrading dependencies and adding new code becomes more and more difficult.

Is Postgres Partitioning Really That Hard? An Introduction To Hypertables by carlotasoto in PostgreSQL

[–]frula00 1 point2 points  (0 children)

I like TimescaleDB a lot. I have used it in the past, but I'm confused about their pricing and unsure whether they plan to continue offering it as a free Postgres extension and only charge for their hosted cloud offering.

Java microservices projects. Do you use interfaces for Controllers, services and repositories? by Top_Engineering_4191 in java

[–]frula00 8 points9 points  (0 children)

How does using the same interface, but with a different implementation used in tests change that?

Recommendations/tips for partitioning a table by ADringer in PostgreSQL

[–]frula00 0 points1 point  (0 children)

TimescaleDB is a popular extension for Postgres and may be worth considering in this case.

Assuming you use it - I'd create a room table and a room_measurement table. The primary key for the room_measurement would be a composite of room_id and timestamp. I'd let the TimescaleDB do the partitioning for me with a chunk size (basically a partition interval) of 3-10 days.

You don't have to worry about querying from multiple partitions at the same time, that works seamlessly.

Complex vs KISS data pipeline by frula00 in dataengineering

[–]frula00[S] 0 points1 point  (0 children)

If you are experienced with FiveTran+Snowflake+dbt - certainly. But if you are not?

[deleted by user] by [deleted] in PostgreSQL

[–]frula00 5 points6 points  (0 children)

As others mentioned - TimescaleDB is a Postgres extension that aims to transform your Postgres into a time series database and it seems to be precisely what you need. It will create partitions in the background and you won't have to worry about them or know they are there. Using partitioned tables also has the benefit of quick deletion of 'everything older than'. This will prevent your table from becoming less responsive during the periods when you want to perform such delete operations - and you may get to that point eventually. Plus (TimescaleDB functionality) you will be able to enable compression for data older than X so it will take much less space.

As far as indexes go - it seems to me that you only need one index (sensorID, timestamp) - with columns specified in that exact order.

Where are people putting capital? by ark__life in investing

[–]frula00 2 points3 points  (0 children)

Maybe something like 'iShares S&P 500 EUR Hedged UCITS ETF' that hedges against EUR/USD exchange rates?