Why We Chose Redshift(blog.amplitude.com) |
Why We Chose Redshift(blog.amplitude.com) |
Edit: Why the downvote? redshift (and flux) exist since before 2010, whereas Amazon Redshift got introduced just in 2012. I think it is reasonable to assume that someone who has never heard of Amazon Redshift would think of the open source project first (that exists in various distributions as packages), and not the Amazon service.
If we took a poll I suspect the majority would be thinking of the Amazon service
That's just personal projection, and is as irrelevant as an argument beginning with, "I think most people would agree that..."
Personally, regardless of Amazon vs UI hack, I'm really tired of ambiguous naming in tech projects.
Not to mention that if you are not already familiar with the company, you probably would not know what sort of blog it was just by looking at what was presented on the HN frontpage. Could have been some random joe-schmoes blog.
(I also came here expecting to read something about the f.lux competitor :) )
[1] http://docs.aws.amazon.com/redshift/latest/dg/cm-c-modifying...
I am considering using a columnar data store (maybe redshift) with a BI tool like bimeanalytics.com specifically to do dashboards.
If you want to use data in real-time, you should be driving it from your transactional systems. Redshift and other data warehouse solutions are for doing reporting and dashboards, not triggering real-time reactions.
You have a complex product/service, with very diverse application scenarios. => Customer adoption is hindered by this complexity. => Customer is not getting value => Customer is angry and stops paying
You hire a person who is familiar with the applications of your technology. He talks to customers to figure out what they want to do, how they plan to achieve it, what the hurdles. He helps them. Writes best practices, implementation plans, helps marketing to position and sales to close.
It turns out so good that you hire many such people, who specialize in particular customer segments. Those people need management.
You need Director of customer success.
It's something between account manager/service/marketing.
Put your data in S3, in csv/tsv/json format, if you want to switch to other provider, just figure out how to import it, and your are all set. How to figure out the limitation of the different platforms and tuning and optimizing is the difficult part.
Data migration is almost always painful and time-spending. When choosing your data provider, you have to be careful because it is very likely to be a long-term commitment. In that sense, in DW world there is always vendor lock-in. Only it is largely driven by the essence of the application itself, less so by the intention of the provider.
Really, vendor lock-in is pretty much a given with data warehousing platforms. Though these days, it's not uncommon for large companies to have multiple DW platforms all pulling data from each other. When one platform falls out of favor, the users just migrate themselves to another since most reporting systems not made by SAP or Oracle are compatible with pretty much everything.
As to SQL language differences, no DW platform uses "standard SQL", just as no two RDBMS use the exact same SQL dialect.
I dare say database platform lock-in is a universal issue. Any migration will involve effort.
I'm presented with information to parse about technology topics daily. Sometimes, I have to search for them and have all sorts of name collisions.
I never, ever search for information about you.
people just can't resist commenting endlessly and upvoting this content-free bikeshedding at the expense of actual discussion
One man's bike shedding is another thousand men's irritating trend. Personally, I very rarely see anyone called out for the trendy names and awful, buzzword-laden non-descriptions that infest projects.
Of course, it gets even more ridiculous as the words get more common, eg see recent discussions about 'Paper' or 'Layout'