3 ms·
Yes! Have an issue for that https://github.com/scratchdata/ScratchDB/issues/19 https://github.com/scratchdata/ScratchDB/issues/19 What would you want it to loo
by memset 3y ago
Yes! Have an issue for that https://github.com/scratchdata/ScratchDB/issues/19 https://github.com/scratchdata/ScratchDB/issues/19
What would you want it to look like?
- NortySpock 3y agoNot the parent poster, but I wouldn't race to solve the problem via supporting many more connectors that require lots of config options. You'll just spend time supporting lots of connectors. Instead, recommend that users use another (connector heavy) tool to get data in -- my mind jumped to using Benthos to convert a CSV or parquet file (or any other input stream) into a series of JSON calls -- and just ask users to hammer ingestion requests at your server. From there, your job is "just" to handle JSON ingestion as fast as you can, rather than maintain many connectors. If JSON becomes a problem, then find exactly one other well-defined file format for bulk data loads (parquet, perhaps?), and support that. When I saw this submission, I think I fell in love. JSON to get data in; SQL to get data out; what could be simpler?
- pitah1 3y agoAgreed. I guess it depends on the target market. If your target is small to medium sized businesses, this is great to start doing analytics. But for large organisations, they generally have ETL/ELT jobs that do all the extraction from data sources to push to an analytics store or save in some format that is performant for analytics and storage (i.e. parquet). I'm also not sure how many data visualisation tools support API endpoints for query serving.