4 ms·

I am sorry - but the subject here misses the point. Just having someone else who can host a cloud MySQL database for you in what appears to be a single location

by adamt 17y ago

I am sorry - but the subject here misses the point. Just having someone else who can host a cloud MySQL database for you in what appears to be a single location doesn't solve the problem that people have running high-availabilty global internet services. The challenges with MySQL are that scaling it effectively to a multiple-master, multi-datacenter solution is almost impossible. Especially if that's over a wide area network.

justinsb 17y ago
The new technology isn't based on MySQL. It's a fully distributed, no single-point-of-failure, scalable relational database. You can choose fully managed hosted traditional MySQL, or we'll be hand-picking early customers for the scalable technology. Contact me if you're interested. We're starting with single-location, but we can certainly support cross-datacenter configurations. CAP seems to dictate that this will either require acknowledgement from the remote datacenter (choose consistency) or a window of loss (choose availability / partition tolerance). Until we see customers regularly hosting their webservers in multiple datacenters, we're going to stay focused on optimizing for a single location. But maybe my viewpoint is out-of-date... How many datacenters are you currently distributing your webservers across?
- btilly 17y ago
  But maybe my viewpoint is out-of-date... How many datacenters are you currently distributing your webservers across? Heh, heh, heh. I work for Google. Need I say more? That said, we like to insist on N+2 globally or N+1 per region. Meaning that if it takes N data centers to host a specific service world wide, we need at least N+2 data centers. And if it is a global application we insist that every region have at least one more data center than needed. (If 2 go down then we can spill across regions, but we'd like to avoid that for latency reasons.) Failover from one data center to another usually is fairly automated. Which means that we are keeping data mirrored on a constant basis. Obviously we're not in your target market. But my suspicion is that as cloud technology becomes more broadly used you should expect variations on our approach to become more common. And therefore you should at least keep the needs of multiple data centers in your head.
  - justinsb 17y ago
    Very interesting - obviously your employer is considerably ahead of the curve compared to where the rest of the market is right now! Care to introduce us to the right person on the AppEngine team? Imagine AppEngine with full SQL support...
    - anamax 17y ago
      Talk to the appscale folks. (Search "appscale".) Google almost certainly isn't going to swap out their appengine stuff for your stuff. However, other folks (especially potential competitors) are potential users.
- deleted 17y ago
  [deleted]
- deleted 17y ago
  [deleted]
- adamt 17y ago
  Your website FAQ question 1 says it's standard MySQL. In another comment here you say: "a new database which we've built ourselves, which we've announced but isn't publicly available yet." If it's standard MySQL, then you hit the same issues as if I were to host MySQL myself. If it's your own database you've built yourself, but is not available yet, then I am not going to trust it with my data. In what I do I often need to have a high-availabilty website where by a loss of connectivity, flood, power issue etc in that data centre can cause outages. Most of the time on our critical projects we have one or two physical data-centers with EC2 for testing and disaster recovery. Although being based in Europe - we do a lot of work in SE Asia. The connectivity between Asia and Europe (often you end up with 400ms+ RTT and 10% packet loss) means you have to host local websites in the region, and even in country (you might be able to drive between Malaysia and Singapore, but the internet inter-connectivity is terrible). If you have any kind of application that ever needs high levels of read-write traffic you quickly end up needing to distribute the database in some way, and for this type of application, it's an awful lot easier to build upon Cassandra and do a bit more work in the application then to try and get MySQL or PostgreSQL to act as a multi-site, multi-master database over sub-optimal links.
  - justinsb 17y ago
    There's a lot we need to do... we just put up the page with the DEMO video today, everything else isn't yet updated to reflect the announcement. This is why we're pursuing both products: if you have a hair-on-fire problem, and are willing to spend the time to investigate and become comfortable with a new DB, then you should use the new database. If you're not there yet and MySQL works for you, we'll run it for you so it's less painful. You've chosen Cassandra because you're obviously in the first group; willing to learn about new databases because of your Asia/Europe pain. You're invested in that, so I'm not going to try to persuade you to change your mind; we're looking to help those that have the same problem, but haven't already locked themselves in to non-SQL databases like Cassandra.

by adamt 17y ago

justinsb 17y ago

The new technology isn't based on MySQL. It's a fully distributed, no single-point-of-failure, scalable relational database. You can choose fully managed hosted traditional MySQL, or we'll be hand-picking early customers for the scalable technology. Contact me if you're interested. We're starting with single-location, but we can certainly support cross-datacenter configurations. CAP seems to dictate that this will either require acknowledgement from the remote datacenter (choose consistency) or a window of loss (choose availability / partition tolerance). Until we see customers regularly hosting their webservers in multiple datacenters, we're going to stay focused on optimizing for a single location. But maybe my viewpoint is out-of-date... How many datacenters are you currently distributing your webservers across?

btilly 17y ago
But maybe my viewpoint is out-of-date... How many datacenters are you currently distributing your webservers across? Heh, heh, heh. I work for Google. Need I say more? That said, we like to insist on N+2 globally or N+1 per region. Meaning that if it takes N data centers to host a specific service world wide, we need at least N+2 data centers. And if it is a global application we insist that every region have at least one more data center than needed. (If 2 go down then we can spill across regions, but we'd like to avoid that for latency reasons.) Failover from one data center to another usually is fairly automated. Which means that we are keeping data mirrored on a constant basis. Obviously we're not in your target market. But my suspicion is that as cloud technology becomes more broadly used you should expect variations on our approach to become more common. And therefore you should at least keep the needs of multiple data centers in your head.
- justinsb 17y ago
  Very interesting - obviously your employer is considerably ahead of the curve compared to where the rest of the market is right now! Care to introduce us to the right person on the AppEngine team? Imagine AppEngine with full SQL support...
  - anamax 17y ago
    Talk to the appscale folks. (Search "appscale".) Google almost certainly isn't going to swap out their appengine stuff for your stuff. However, other folks (especially potential competitors) are potential users.
deleted 17y ago
[deleted]
deleted 17y ago
[deleted]
adamt 17y ago
Your website FAQ question 1 says it's standard MySQL. In another comment here you say: "a new database which we've built ourselves, which we've announced but isn't publicly available yet." If it's standard MySQL, then you hit the same issues as if I were to host MySQL myself. If it's your own database you've built yourself, but is not available yet, then I am not going to trust it with my data. In what I do I often need to have a high-availabilty website where by a loss of connectivity, flood, power issue etc in that data centre can cause outages. Most of the time on our critical projects we have one or two physical data-centers with EC2 for testing and disaster recovery. Although being based in Europe - we do a lot of work in SE Asia. The connectivity between Asia and Europe (often you end up with 400ms+ RTT and 10% packet loss) means you have to host local websites in the region, and even in country (you might be able to drive between Malaysia and Singapore, but the internet inter-connectivity is terrible). If you have any kind of application that ever needs high levels of read-write traffic you quickly end up needing to distribute the database in some way, and for this type of application, it's an awful lot easier to build upon Cassandra and do a bit more work in the application then to try and get MySQL or PostgreSQL to act as a multi-site, multi-master database over sub-optimal links.
- justinsb 17y ago
  There's a lot we need to do... we just put up the page with the DEMO video today, everything else isn't yet updated to reflect the announcement. This is why we're pursuing both products: if you have a hair-on-fire problem, and are willing to spend the time to investigate and become comfortable with a new DB, then you should use the new database. If you're not there yet and MySQL works for you, we'll run it for you so it's less painful. You've chosen Cassandra because you're obviously in the first group; willing to learn about new databases because of your Asia/Europe pain. You're invested in that, so I'm not going to try to persuade you to change your mind; we're looking to help those that have the same problem, but haven't already locked themselves in to non-SQL databases like Cassandra.