- What is Fuji?
- What is SQL Anywhere OnDemand Edition?
- Is SQL Anywhere OnDemand Edition a database?
- Is SQL Anywhere OnDemand Edition a new database?
- Is SQL Anywhere OnDemand Edition a service that is hosted by Sybase?
- How is SQL Anywhere OnDemand Edition different from existing relational databases?
- How does SQL Anywhere OnDemand Edition distribute the workload across multiple machines?
- How does SQL Anywhere OnDemand Edition scale?
- Who is the target customer for SQL Anywhere OnDemand Edition?
- What advantages does the “Single database per customer” model bring?
- If SQL Anywhere OnDemand Edition is designed to scale with the number of databases, how does it handle the scalability of a single database?
- Usage Tracking
"Fuji" is the codename for the first release of a new product from Sybase, SQL Anywhere OnDemand Edition.
SQL Anywhere® OnDemand Edition is a data management solution that enables ISVs to take business applications to the cloud without compromise. Now ISVs can build, deploy, and manage large cloud applications that put customers first.
Your customers’ data is isolated, and they always know where their data is. SQL Anywhere OnDemand Edition delivers trusted data management capabilities that let you take advantage of the cloud’s economies of scale, with built-in tooling that ensures you can still treat each of your customers individually. SQL Anywhere OnDemand Edition gives your customers the security of full data isolation while giving you the administrative ease of multi-tenant computing.
Yes, but it is much more than that. SQL Anywhere OnDemand Edition is a distributed database server that can be spread out across many machines, but logically can treated as a single server from the outside world.
SQL Anywhere OnDemand Edition is built on top of an existing database from Sybase, SQL Anywhere. SQL Anywhere is an embedded database that used by ISVs building data-rich applications. SQL Anywhere is used by thousands of partners, and is deployed to millions of users.
No, SQL Anywhere OnDemand Edition is a piece of software that developers can take and run on whatever hosting provider they like. It allows developers to create a distributed, scalable database that they can use to power their cloud applications.
SQL Anywhere OnDemand Edition allows you to create a cloud of machines that act as a distributed database engine. From the outside, applications are able to connect to the cloud of servers and treat it as if it were a single server. Internally, the workload is balanced across many different servers that make up the cloud. These servers can be dynamically added and removed in order to provide scalability as demand changes.
SQL Anywhere OnDemand Edition takes a fundamentally different approach to scaling across many machines; it is designed to scale with the number of individual databases in the cloud, not the absolute size of any single database.
SQL Anywhere OnDemand Edition does not shard or partition pieces of any database across all the machines in the system. Each database stays completely intact on the machines that it runs on. Queries are executed at one machine only, and are not distributed across multiple machines.
Scalability comes in many forms, and it is important to identify by what metric you scale. Most cloud databases have been focused at the problem of scaling the absolute amount of data stored. To do this, they use complicated shading and partitioning techniques. SQL Anywhere OnDemand Edition is different. SQL Anywhere OnDemand Edition scales with the number of individual databases that are run in the cloud.
Because SQL Anywhere OnDemand Edition is focused on scaling with the number of databases in the cloud, it is targeted at users who have a large number of separate, isolated databases that they need to manage.
The most obvious group that falls into this category are Independent Software Vendors (ISVs). ISVs create applications that they resell to many separate customers. When an ISV develops an application for the cloud, they are faced with the choice of how to organize their customers’ data. Typically, they are faced with two options: put all the customers into a single database, or maintain separate databases for each customer.
We believe that for most ISV applications, the right choice is to maintain separate databases for each customer. The result of this is that the ISV is faced with the task of managing hundreds or thousands of individual databases. This is the task that SQL Anywhere OnDemand Edition makes easier.
Although ISVs are the most obvious group, SQL Anywhere OnDemand Edition is suitable for anyone that is responsible for hosting many databases, and wants to centralize and manage them in a single data platform.
For an ISV, every customer is separate and unique from all of the other customers. And, just as the customers are separate, their data is separate as well. For ISVs who have existing deployed applications, this is the model that their applications were written in by necessity. Because the application was deployed at each customer’s site, each customer had their own instance of the application and database. As ISVs create hosted solutions that compliment or replace their existing deployed application, they must decide whether to maintain that data model in the new application.
Keeping the databases separate gives ISVs more flexibility to treat their customers individually. These benefits fall broadly under four separate categories:
- Data isolation. Customers want to know that their data is physically isolated from that of other tenants. Data isolation is critical for privacy, but in some industries it is a requirement for compliance with industry-specific regulations such as HIPAA in healthcare, PCI-DSS in credit cards, and Sarbanes-Oxley in financial markets.
- Data locality. Despite the promise that cloud computing frees you from worrying about the physical location of data, in reality it does matter. Country specific laws and requirements (such as the U.S. Patriot Act) impose limitations on how freely a company’s data can be copied and replicated to other data centers. Customers want to feel secure that they can set limitations on where their data can and cannot reside. By maintaining separate isolated database, ISVs are able to provide this service and give their customers full visibility into where their data is stored.
- Customization. Many customers want to customize their databases to support a specific feature that is only useful to them. Without the ability to isolate one tenant’s data from another, this is difficult (if not impossible) to support
- Data Access. Customers want to access to their own data as freely in SaaS models as they do in on-premise models. They may want to perform backups, or pull data into spreadsheets for reporting and queries. If all customers data is co-mingled can make it difficult for customers to extract their own data from that of other tenants.
Until now, the main drawback to maintaining separate database has been the administrative overhead associated with managing, backing up, and tuning thousands of databases. SQL Anywhere OnDemand Edition solves this problem; it is designed to allow a small team to manage thousands of isolated databases.
While SQL Anywhere OnDemand Edition is focused on the scalability of the number of databases, the scalability of each individual database is important. Because SQL Anywhere OnDemand Edition is powered by the SQL Anywhere database, the scalability of an individual database is identical to that of existing SQL Anywhere databases. SQL Anywhere OnDemand Edition is targeted at running databases up to hundreds of gigabytes in size. (Note that is the size for an individual database. Because SQL Anywhere OnDemand Edition is designed to run many databases, there may be hundreds of database of that size making the absolute size of data stored in the cloud much greater).
The cloud uploads, via a secured HTTPS connection to the Sybase billing server, an XML document that contains the following cloud-level pieces of information:
- License key
- Name of the company to which the server is licensed
- Name of the cloud
- GUID of the cloud
- Fuji version number
and then the following server-level pieces of information:
- The ID of each server and the ID of the host it is running on (note that the actual names of servers and hosts are not uploaded)
- The fraction of the hour that the server was running
- The total number of CPU cores (including threads, if hyperthreading is enabled) on the server machine and the number that the server can use (ie. the -gtc server setting)
- The total number of CPU seconds accumulated by the server during that hour
- The average file size of all dbspaces (excluding the temp dbspace and transaction log)
- The average number of connections to the server for that period
Here is an example usage document for a two-server cloud:
In the Fuji Beta, the cloud will upload its usage information to Sybase every hour. If for some reason it can't establish a connection to Sybase, a cloud error will be generated. The error will continue to be generated every hour until the upload succeeds.
If a cloud has not successfully uploaded its usage information for 31 days, it will enter reduced-functionality mode until it can successfully upload its usage data. In reduced-functionality mode, all running servers continue to run, however, no cloud tasks can be executed. This means that, for example, no new servers can be started in the cloud while it is in reduced-functionality mode. While in this mode, it will continue trying hourly to upload its data. The most common reason for the cloud to be unable to upload its usage information is that it can't establish an HTTPS connection to relayserver.sybase.com.
The verbatim XML file that is uploaded to Sybase is written out in the cloud event tracing log. You can see exactly what has been uploaded by doing the following:
- Get the .etd event log (more information )
- Run dbmanageetd diagnostic_log.etd > diagnostic_log.txt
- View the text file, and search for the phrase "Usage information details"; at this line, you will see the exact document sent to Sybase