NewSQL versus otimização tradicional / sharding [closed]

Somos uma startup pequena com um aplicativo SAAS de gravação pesada e estamos (finalmente!) Chegando ao ponto em que nosso uso está apresentando problemas de dimensionamento. Nós temos uma pequena equipe, então nós realmente apreciamos poder descarregar sysadmin para Heroku e RDS.

Enquanto o Heroku está (principalmente) bem, nós temos alguns problemas com o RDS:

Escala Essa é a maior preocupação. Atualmente, executamos uma instância do XL RDS. Conseguiremos sobreviver por mais algum tempo com otimizações simples, mas, a menos que façamos algumas mudanças estruturais importantes em nosso aplicativo, chegaremos a um gargalo em algum momento.

Além disso, o tempo de inatividade para alterar o tamanho da instância é uma droga.

Disponibilidade. Nós executamos uma instância multi-AZ, então devemos sobreviver a uma única interrupção de AZ. Mas o RDS é construído sobre o EBS, o que me deixa bastante preocupado com a história e o design do EBS.

Preço. Nossa conta RDS é 4x o que pagamos Heroku. Eu não me importo de pagar a Amazon para me salvar de contratar um administrador de sistema, mas eu adoraria encontrar algo menos caro.

Na minha opinião, temos duas opções para avançar: a abordagem tradicional (sharding, executar um job noturno para mover partes de nosso banco de dados para somente leitura, etc.); ou uma solução NewSQL (Xeround, VoltDB, NimbusDB, etc).

Prós tradicionais: Tem sido feito muitas vezes antes e existem maneiras bem padronizadas de fazer isso.

Contras tradicionais: vai dar muito trabalho e introduzir uma complexidade significativa no aplicativo. Também não resolverá os problemas secundários com RDS (disponibilidade e preço).

Prós NewSQL: Supostamente, essas soluções escalarão horizontalmente nosso banco de dados sem alterar o código do aplicativo (sujeito a algumas restrições na funcionalidade do SQL, como não usar o bloqueio pessimista). Isso nos pouparia uma enorme quantidade de trabalho. Também melhoraria a confiabilidade (sem um único ponto de falha) e reduziria os custos (não ter que executar uma instância do XL durante as horas de folga apenas para fornecer o uso de pico).

Contras NewSQL: essas soluções são relativamente novas e não consegui encontrar boas críticas ou anotações da experiência das pessoas com elas em aplicativos de produção. Eu só encontrei um disponível como uma solução hospedada (Xeround), então a menos que tenhamos que ir com aquele, teríamos que investir recursos em sysadmin.

Eu estou querendo saber quais são as opiniões sobre qual seria a minha melhor opção.

Xeround é muito tentador (hospedado NewSQL), mas eu não fui capaz de encontrar qualquer bom uso da informação na produção. Os poucos tweets que eu vi foram pessoas reclamando que era um pouco lento. Estou bem nervoso em mudar para algo que parece tão não testado.

O lado conservador de mim diz para ficar com o RDS e usar uma abordagem tradicional. Mas será muito caro em termos de tempo de desenvolvedor.

E então parte de mim se pergunta se há outra maneira, talvez uma solução hospedada em NewSQL mais testada em batalha que eu não tenha ouvido falar. Ou talvez uma solução NewSQL, nós teríamos que nos hospedar, mas isso tem uma história realmente sólida.

Agradecemos antecipadamente por seus pensamentos.

questionAnswers(3)

yourAnswerToTheQuestion