JP6552196B2 - Cloud-based distributed persistence and cache data model - Google Patents

Description

  The present invention uses a cloud-based distributed persistence and cache data model with a structured query language (SQL) application interface to improve cloud computing scalability and reduce latency, and Provide a method.

  Cloud computing environments can provide infrastructure, applications, and software over networks on the web. Early web-based infrastructures were based on mainframe or server-based relational database models and n-tier network clustering application servers. As the web grew into an interactive platform, the infrastructure became two front-data and application layers. There are a number of solutions for the application layer, and linear scalability is fairly easily achieved by using an off-the-shelf solution, and the application layer is model view controller (MVC) architecture. Provide views and controllers. The data layer essentially constitutes a model in the MVC architecture. The data layer provides unstructured / structured data for the application using one of database management systems including relational databases, object-oriented databases, and key / value pair databases.

Relational Databases Relational databases are known in the art. Relational databases are structured data stores that store various data types in the form of bits and bytes in structured tables that can be accessed using Structured Query Language (SQL). The origin of the relational database can be traced back to relational algebra. The basic premise of current relational database offerings is that the data needs to be accessible independently of any hardware or software via a standardized interface. Initially, data elements are independent by minimal or zero relationship attributes. As database engines become more powerful, data structures and relational data graphs become more complex as relationships between tables and data elements become more complex. Essentially, a relational database is a collection of tables comprised of rows and columns with SQL interfaces for applications accessing the database. Relational databases have provided the best mix of simplicity, robustness, flexibility, performance, extensibility, and compatibility when managing generic data. Regardless of the vendor supplying the database, all relational databases require data structuring without exception. The disadvantage of a relational database management system (RDBMS) is that it cannot be distributed across physical machine boundaries seamlessly or dynamically over the network, unless using partitioning and / or sharding that requires manual intervention and maintenance. It is.

  This manual intervention needs to overcome the physical limitations of the amount of data that can be stored within the physical boundaries of a single machine or in an external data array. Before the advent of Web 2.0 and its large scale of data, the above scenario was constantly growing as the computing power of single machines with multi-core computing units grew faster than the data growth of most mechanisms Although able to work, the data scale for current applications grows exponentially every day, and the above assumptions do not apply. The above drawbacks make the relational database inconvenient for current and future cloud based applications with data scales that are exabyte and zettabyte, in addition to extremely high licensing and support costs.

Relationships / Object Relationships Databases Since relationship database design precedes object-oriented design paradigms by one or two generations, there is a lack of true support for complex object graphs. Advances in information complexity cause another drawback to relational databases. Relational databases are specifically created to organize data by common characteristics. Complex images, numbers, designs, and multimedia products make it impossible to easily categorize and ultimately lead to complex object graphs that turn into unstructured data. Bringing a way for a new format. Current systems are designed to handle more complex applications and require the ability to be extensible and distributable in the cloud. Object-relational databases do not meet the requirements because they are not extensible or network distributable, and are therefore inadequate.

Key / Value Databases The new Web 2.0 paradigm handles data measured in terabytes and petabytes as opposed to gigabytes. Although relational databases have been functioning for 40 years, they are not suitable for processing rapidly growing data in terabyte sizes on a daily basis. The main reason for this shortcoming is that, for relational databases, extensibility is directly related to the computing power of the underlying machine or split machine. Prior to the advent of Web 2.0, which added social networking aspects to all facets of computer processing, advances in server design have expanded the database to serve the needs of applications. However, to handle petabytes and larger volumes of data, new types of database management systems have become established, using key / value stores known as non-relational database management systems (non-RDBMS) or schemeless databases There is. New types of database management systems are commonly referred to as non-relational and / or NoSQL databases that use key / value stores. In practice, there is no standard name yet, document-oriented, internet-facing, attribute-oriented, distributed database (although it can also be related), shard sort array, distributed hash table, or key / value It can be called a database. Each of these names represents a particular feature of this new scheme, but these are all variations on one subject that we call the key / value database. Several options, including the following, are available in the current market with this new key / value scheme.

  Cassandra (Kassandra) is an open source distributed database management system. This is the Apache Software Foundation's top level project designed to handle high volumes of data that is spread across many commodity servers while providing high availability services without a single point of failure. This is a NoSQL solution that was originally developed by Facebook and makes those inbox search features powerful. Cassandra is a BigTable data model that runs on an infrastructure such as Amazon-Dynamo.

  Cassandra provides structured key-value stores with result consistency. Keys are mapped to multiple values grouped into column families. The column family is fixed when the Cassandra database is created, but columns can be added to the family at any time. In addition, columns are added only to the specified key, and different keys can have different numbers of columns in any given family.

  The values from the column family for each key are stored together, making Cassandra a hybrid between a column-oriented DBMS and a row-oriented store.

  In general, Apache CoachDB, called CoachDB, is a free open source document-oriented database written in the Erlang programming language. It is a NoSQL product designed for local replication and extends vertically along a wide range of devices. CoachDB is supported by the commercial businesses CouchOne and Cloudant.

  HyperTable is an open source database that starts with publishing GoogLe's BigTable design. The project is based on the experience of engineers who have solved large data intensive tasks. The hypertable is executed on top of a distributed file system (DFS) such as Apache Hadoop DFS, Glasta FS, or Cosmos File System (KFS). This is almost entirely written in C ++ for performance.

  MongoDB is an open source, extensible, high-performance, schema-free, document-oriented database written in the C ++ programming language. This database is document-oriented because it manages a collection of documents such as JSON. Thus, many applications can model data in a more natural way, as the data can be nested in complex hierarchies and queryable and indexable. MongoDB's development began in October 2007 by 10gen. The first release was in February 2009.

  TokyoCabinet is a library of routines for managing databases. A database is a simple data file that contains records, each of which is a key-value pair. All keys and values are variable length serial bytes. Both binary data and strings can be used as keys and values. There is no data table concept or data type. Records are organized into hash tables, B + trees, or fixed length arrays. Tokyo Cabinet has been developed as a successor to GDBM and QDBM.

  Voldemort is not a relational database, it does not attempt to satisfy attribute relationships while satisfying ACID properties, it is not an object database that attempts to map object reference graphs transparently, it introduces new abstractions such as document orientation. There is no introduction. This is basically a large distributed permanent fault tolerant hash table. For applications that can use O / R mappers such as active recording or hibernate, Voldemort offers horizontal extensibility and higher availability, but at the cost of greater convenience. In large applications under the pressure of Internet type scalability, the system is likely to consist of several functionally partitioned services or application programming interfaces, which can be partitioned horizontally. A storage system can be used to manage storage resources between multiple data centers. For applications in this space, arbitrary in-database joins are already impossible, as all of the data is not available in any single database. A typical pattern is to introduce a caching layer that requires hash table semantics in some way.

  Drizzle can be thought of as a countermeasure to the problem that the key / value store seeks to solve. Drizzle began as a derivation of the MySQL (6.0) relational database. Over the last few months, this developer has slimmed down non-core feature hosts (including views, triggers, prepared statements, stored procedures, query cache, ACLs, and some data types) In order to create a simple high-speed database system. Drizzle can store relational data and the goal is to build a quasi-relational database platform for web and cloud-based applications running on systems with 16 cores or more.

  The biggest drawback of the distributed key / value database as described above for applications with complex object graphs is the latency in response time and the lack of features that we consider natural in some off-the-shelf generic relationship databases. Most if not all of the current social networking applications require extremely complex object graphs.

  BigTable is a compressed, high-performance, dedicated database system built on the Google file system, ChubbyLockService, SStable, and several other Google programs that are now distributed or used outside of Google. Although not, Google recommends access to it as part of the Google application engine.

  HBase is an open source non-relational distributed database modeled after Google's BigTable, written in Java. It was developed as part of the Apache Software Foundation's Hadoop project, runs on top of the Hadoop distributed file system, and provides features like BigTable for Hadoop. This provides a fault tolerant method of storing large amounts of sparse data.

Database Memory Cache With the advent of the dynamic web, the latency of data access time has come to affect the performance of web pages. The latency in data access time for both reads and writes is linearly related to the access time of the hard drive holding persistent data. To remove the obstacles of accessing the disk to get information, computer developers use the shared memory / cache concept as a way to reserve a portion of memory (RAM) on the server for frequent reading of the same data. I figured it out. By caching data for reading, the need for frequent disk access is eliminated, thus reducing data latency. As time progresses, the cache grows more exotic. Various available options include: Google Cache; cache tables from CSQL cache-MySQL, Postgres and Oracle; Memcached-cache result set of queries; TimesTen-cache ORACLE tables; and SafePeak-for full data accuracy Includes automated caching of query result from SQL server and result set of procedure by automated cache eviction. Memcached is a free and open source, high performance, distributed memory object caching system that is general in nature but intended to be used to speed up dynamic web applications by reducing database load. ing. Memchached is an in-memory key-value store for small chunks of database calls, application programming interface calls, or arbitrary data (strings, objects) from the results of page rendering.

  All three mainstream approaches to interaction between structured data and applications (with cache) are pros and cons. The present invention provides a solution to a new cloud-based paradigm by presenting a fully functionally relevant and fully distributable data store in the cloud in a single package.

  The present invention provides systems and methods for enhanced scalability and reduced latency in a database hierarchy for cloud computing. These include systems that include a cache adapter that can store data in either a relational or non-relational (structured or unstructured) database format, which is a data adapter for data persistence Communicate with the client cache on the front end of the client database (cache) for data synchronization from the distributed file system at the back end of the cache and the distributed file system.

  BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are used to provide a further understanding of the present invention and which are incorporated in and constitute a part of this specification, are illustrative of the present invention, together with a description for the purpose of illustrating the principles of the invention. An embodiment is shown.

It is a figure which shows the flow of the data between the cache adapter and client in embodiment of this invention. FIG. 5 illustrates data flow and synchronization between a distributed file system utilizing a cache adapter and a client according to an embodiment of the present invention. 4 is a flow diagram illustrating the flow of data following a client request made using an embodiment of the present invention. 4 is a flow diagram illustrating the flow of data following a client login to set up a user persona using an embodiment of the present invention. It is a figure which shows the data cell in embodiment of this invention. FIG. 4 illustrates user subscription to one or more vertical applications in an embodiment of the present invention. FIG. 2 illustrates the architecture of a particular embodiment of the invention in which a client communicates with a single instance of a database. FIG. 6 is a diagram illustrating backend synchronization with user data in a data cell with a client machine database according to an embodiment of the present invention. FIG. 5 illustrates the architecture of a particular embodiment of the invention in which multiple instances of the database communicate with the client in parallel. FIG. 4 illustrates the architecture of a particular embodiment of the present invention in which multiple instances of a database communicate with a client in parallel and each client has its own database instance. FIG. 6 illustrates the architecture of a particular embodiment of the present invention, which allows the cache adapter to interact with the database for data persistence purposes, which will in turn store the data in the distributed file system.

  The present invention is not limited to the various specific methods, compounds, materials, manufacturing techniques, uses, and applications described herein. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of the present invention. The singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise. Thus, a reference to "an element" is a reference to one or more elements, including equivalents known to one of ordinary skill in the art. Similarly, in another embodiment, a reference to "a step" or "a means" is a reference to one or more steps or means, and may include substeps and dependent means. All conjunctions used should be understood in the most inclusive sense possible. Thus, the term "or" should be understood as having a logical "or" definition rather than a logical "exclusive or" unless the present context expressly requires otherwise. The structure described should be understood to represent a functional equivalent of such a structure. Terms that can be construed as expressing an approximation should be understood as such unless the context clearly indicates otherwise.

  Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although preferred methods, techniques, devices, and materials are described, any method, technique, device, or material similar or equivalent to that described herein can be used in the practice or verification of the invention. it can. It is to be understood that the structures described herein are indicative of functional equivalents of such structures.

  All patents and other publications identified are incorporated herein by reference, for example, for the purpose of explaining and disclosing the methodology described in that publication that may be used in connection with the present invention. These publications are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the inventor is not entitled to antedate such disclosure by virtue of prior inventions or for any other reason.

  As used herein, the term “automatic” and variations thereof refer to any process or operation that occurs without tangible human input when the process or operation is performed. However, if the input is received prior to execution of the process or operation, the process or operation may be automatic, even though the execution of the process or operation uses tangible or intangible human input. Human input is considered tangible if such input affects the manner in which the processing or action is performed. Human input that consents to perform a process or action is not considered “tangible”.

  The term “computer-readable medium” as used herein refers to any tangible storage device that participates in providing instructions to a processor for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, NVRAM, or magnetic or optical disks. Volatile media includes dynamic memory, such as main memory. Common forms of computer readable media are, for example, floppy disks, flexible disks, hard disks, magnetic tapes or any other magnetic media, magneto-optical media, CD-ROM, any other optical media, punch cards, It can be read by paper tape, any other physical media with a pattern of holes, RAM, PROM, and solid media such as EPROM, FLASH-EPROM, memory cards, any other memory chip or cartridge, or computer Any other media is included. If the computer readable medium is configured as a database, it should be understood that the database can be any type of database such as relational, hierarchical, object oriented, and / or the like. Accordingly, the present invention is considered to include tangible storage media on which the software implementation of the present invention is stored and equivalents and replacement media recognized in the prior art.

  As used herein, the terms “determining”, “computing”, and “computer computing” and variations thereof are used interchangeably and include any kind of methodology, processing, mathematical operations, or techniques. .

  As used herein, the term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or hardware and software capable of performing the function associated with that element. The combination of is shown. Also, while the invention is described with respect to exemplary embodiments, it should be understood that individual aspects of the invention can be claimed separately.

  As used herein, the term “communicate with” refers to any coupling, connection, or use of electrical signals to exchange information or data using any system, hardware, software, protocol, or format. Show dialogue.

  The terms "virtual" or "virtualization" as used herein refer to a logical representation of some other component such as a physical disk drive. In other words, a "virtual" component is not actually the same as the physical component that the "virtual" component represents, but looks the same to other components of the computer system, hardware, software, etc.

  As used herein, the term “disk” refers to a storage disk or other memory that can store data for a computer system.

  As used herein, the terms "cloud" or "cloud computing" refer to Internet-based computing, and the resources, software, and information shared thereby are on demand like computers and other like public facilities. Provided on devices.

  Cloud computing is, in a broad sense, virtualization of standard components of computer systems. It uses both data and software, usually contained within a single computer, and extends to these and other remote components. For example, a client or user can access a server or database to obtain information programmatically when information is stored in one location, a query is processed by software at another location, and the client is still in another location. Can be accessed. In practice, the software can create a virtual server that operates as a single server while maintaining data storage at a plurality of disparate physical locations. Regardless of the software mechanism used to access the data, query processing typically includes a cache that operates as a relational database instance with a distributed file system for data persistence. A cache is a data storage component that stores or retrieves data from a distributed file system in a manner that allows data to be stored and provided in the distributed file system faster in response to client requests. The data stored in the cache can be a duplicate of the data stored anywhere in the system, or can be data generated in response to a previous client request or query. All of the data in the cache is eventually synchronized to the distributed file system and client cache. A cached data storage map directory holding data cell locations is typically used as a means to communicate with data cells in the cache.

  Various embodiments of the present invention are designed to improve the speed with which data can be accessed and stored, while at the same time providing enhanced scalability. In one embodiment, the cache adapter includes data cells capable of storing data in a relational database table format, the cache adapter in communication with the distributed file system and the client cache. In another embodiment, the cache adapter includes data cells of multiple database instances that can store data in a relational database table format, and the cache adapter communicates with the distributed file system and the client cache. It is believed that the cache adapter can incorporate cache and maintain back-end connectivity to the distributed file system with front-end client databases residing on client machines. In an alternative embodiment, a cache adapter can communicate between an existing cache and a relational database or other type of database as an intermediary to the distributed file system. A cache adapter can be composed of small data cells. The cache adapter can move data between data cells in the cache and the distributed file system.

  In the embodiment of the present invention, the cache adapter exists in front of the cloud distributed file system. This cache adapter creates CloudCache and provides an interface for all external clients to access the database. This CloudCache is a contiguous space that spans all available designated systems described in the configuration file. The cache adapter sends the data access request to the appropriate data cell stored in the cloud. These data cells can persist data permanently in a cache distributed in the cloud in addition to the cloud distributed file system. Furthermore, the cache adapter can allow access to data residing in the cloud distributed file system directly without going through the cache, if necessary. This can realize large bulk loads or large data searches and alleviate the need to access multiple data cells with a single request. In response to a request for data from the client, the cache adapter first checks whether the data is available in the cache, and if the cache really has the requested data, the system provides the data from the cache. However, if the data is not in the cache, the system automatically retrieves the data from the distributed file system and caches it before sending it to the client, thereby satisfying the data request. This process is shown below with the data flow diagram of FIG.

  In particular embodiments, the cloud distributed cache acts as a relational database with a SQL interface for applications interfacing to this cache adapter. For example, as shown in FIG. 11, the cache can be supported at the back end by a fully distributable file system in the cloud for data persistence. Using this setup, the database grows as a linear function of the hardware, providing potentially infinite scaling. In the region beyond exabytes, there can be a final threshold. The cache adapter of the present invention can be integrated into a distributed file system. The adapter can fully incorporate data from the cache in a structured relational data format, then convert it to a distributed file system or intermediate database for real-time dynamic storage and distribute it on the return path Convert data from a file system or intermediate database to a cache-compliant format.

Adapter framework and data flow For example, as shown in FIG. 1, all external clients interface to the cache adapter via a web server, so that the gateway for the client uses the standard secure https interface. Communication with the database. The cache adapter 100 communicates bi-directionally with the web server 110, and the web server 110 bi-directionally communicates with the client. The client may be a mobile device specific application client 120 or an HTML 5 application client 121. The presentation layers 130, 131 and the client databases 140, 141 are contained within the clients 120, 121.

  The cache adapter can interface internally to data cells and file systems using a standard Java Database Connectivity (JDBC) interface. Each individual data cell can permanently persist data in the cloud distributed file system. The data present in the cache will be in a structured form similar to the relational database table format. However, the data present in the cloud distributed file system is in an unstructured format. An adapter processing framework is required to convert data from one format to another depending on the function call, read / write requirements.

  Typically, the cache (Alternatively, CloudCache in showing cache as one continuous unit across multiple machines) is a reserved part of memory. As shown in FIG. 2, the cache adapter 200 may be used for its own use as one or more nodes 260, 261, 261 in a networked cluster (physical and / or virtual) of machines as a continuous space, CloudCache. Reserve specified portions of 262 individual RAMs. The process sets up two more connections, one from CloudCache to the distributed file system below, and another from CloudCache to the cloud via lightweight application server 250 and web server 210. The cache adapter uses this designated memory space to store data in the data cells. Although each data cell is flexible in its data size, there are upper limits specified in the configuration file to facilitate maintenance and consistent functionality of the entire infrastructure. External applications can interface to the cache adapter using an interface that is a standard JDBC interface or an extension of a standard https interface. External applications cannot communicate directly with data cells. Data cells are an integral part of the process.

  The cache adapter stores data in data cells in the cache in relational database table format. This differs from traditional relational database management systems (RDBMS) in the sense that the data is present in cache and not in standard operating system file systems, including distributed file systems. The data present in the cache is persistent and not volatile, and cloud distributed file systems are used for persistence. A conventional RDBMS stores data in a disk file system, and some databases can cache portions of data with low latency, but both of the two media are completely distributed in the cloud as a single entity Not. Sharding can provide a similar function, but is not seamless and therefore requires significant customization and has other limitations.

  A data cell contains user data for a single or multiple users. Each individual data cell includes a plurality of data tables. These tables contain data for single or multiple users. The cache adapter automatically determines the user's data space requirements, retrieves data for the user, or stores new data entered by the user.

  The cache adapter communicates with the external distributed file system and converts data from the client cache to the distributed file system and data from the distributed file system to the client database as shown in FIGS.

  A definitive description provides examples only, and does not limit the scope, availability, or configuration of the present invention. Rather, a definitive description will provide those skilled in the art with a viable description for carrying out the embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope of the claims. For example, the invention finds applications for social networking, client / customer management and services, financial and business services, healthcare record management, transaction management, sales, marketing, analysis, security alerts, intelligence gathering, and collaboration. it was thought.

EXAMPLE Architecture-Systems and Components for Cloud-Based Social Networking Infrastructure In a specific embodiment of the present invention, the cache adapter improves existing social networking site architecture by improving both performance and scalability. Improve. Social networking sites, such as Facebook®, Twitter®, LinkedIn®, etc., are only some form of subset of contact relationship management (CRM) spectrum. These networking sites allow their authorized users (individuals / entities) to create personal profiles, build their social relationships, and extend and nurture them as they interact with each other. Many sites within this subset of CRM spectrum utilize the internet browser as a client to interact with the n-tiered web infrastructure. The present invention can be utilized to provide a next generation social networking site supported by a robust architecture that is interactive and massively extensible. The system of the present invention is comprised of clients supported by the back end infrastructure.

  All major offerings present in the current market use an Internet browser with which the client interacts. The client searches or presents new information via this internet browser. The browser forwards the request to the application server, which processes these incoming requests. The application layer interacts with the database at the back end as part of the process. Many such sites are supported by relational databases at the back end, creating data flow bottlenecks. The relational database approach is (1) based on an asynchronous http request and response system where the architecture requires a continuous internet connection, without the internet connection the browser stops and stops responding (2) response time is generally slow (3) An additional feature is a difficult task if it requires simultaneous changes in both the application layer and the backend database. (4) The software upgrade release cycle is difficult and time consuming, and ( 5) Including the following disadvantages of maintaining the infrastructure cost.

  The present invention can provide an infrastructure consisting of currently existing standard browser-based clients, as well as backends that provide significantly different workflow and data flow features from current offerings. The client of the present invention is an application code for the presentation layer, either as an HTML5 client or a proprietary application specific to the original operating system, in particular iOS (Apple's iOS) and Google's Android (Registered Trademark). Can be configured. Regardless of whether the client is an HTML5 client for a PC or a dedicated application for a proprietary mobile device OS, the client does not always access the backend database directly. Clients mostly access a small footprint of user data on a local database residing on the client machine. If required, the client seamlessly retrieves additional data from the back end that is all present in the cloud as opposed to the relational database. Furthermore, the back end synchronizes the client database with the latest update data from the back end without any client intervention in addition to sending the data to the client, and the data's data without additional or further client interaction. Keep syncing.

  Another differentiation exists when the current offering delivers HTML pages compiled server-side with the MVC (Model View Controller) object design pattern. In the MVC pattern model, the controller is a module that receives and processes all requests from clients. The view, the presentation layer, is then compiled and then delivered to the browser with an HTML stream, which is displayed by the client browser web server.

  In the back end, the system of the present invention starts an Internet / cloud facing industry standard web server such as Apache.

Application Server In the old model n-tier web architecture, the middle tier consists of a dedicated application server such as WebSphere, Oracle, etc. Here, there is no need for a full-fledged J2EE application server component in the architecture of the present invention. The lightweight application server acts as a controller / dispatcher and is embedded in the cache adapter. The main reason for this is that in the present embodiment of the process the application code is sent where the data is present, as opposed to transferring the data where the application code is present. The client has a small footprint database, which always synchronizes itself to the backend database. The client accesses the local database to present data to the user. While presentation layer code resides on the mobile device client's client, in HTML5 clients, presentation layer code resides on HTML5.

Database Server As shown in FIG. 2, the database layer is composed of a cache adapter 200 located at the top of the distributed file system 270. As mentioned above, in contrast to the true n-tier architecture with separate application and data layers, anything currently designed in the sense that lightweight application server 250 is incorporated as part of cache adapter 200 It is different. There are two data cache components in the system of the present invention. That is, one resides on the client as a client database (cache) 240, 241 specific to the client machine, and the other data cache consists of nodes 260, 261, 262 residing, for example, on clustered nodes residing in the cloud It is CloudCache. The CloudCache is located in the upper node of the distributed file system 270, that is, the clustered node existing in the cloud as shown in FIG.

  The system of the present invention may have two main components: a lightweight web server cluster 210, and a cache adapter 200 (which incorporates a lightweight application server 250) acting as a database server according to the present invention. FIG. 3 shows the data flow of the system. Clients can submit two types of requests to the back end. The request can either be a retrieval of stored data or a presentation (storage) of new data.

  The data retrieval request according to the invention is simple. Client 300 requests data 310 that may be available in the client machine's local database, and if so, the request does not leave the client machine and is satisfied within the boundaries of the client machine. In instances where the data does not exist in the client machine cache, the request is presented to the backend. If the requested data does not exist in the client database, the incoming request is intercepted by the cache adapter's storage map 325 to provide the location of the requested data to the request. The data location is a pointer to the cached data if the data is not in the cache, and then the data (archive data) is retrieved from the distributed file system in a raw unstructured format 360. Data from the distributed file system is retrieved first, then converted to cache compatibility format 355 and finally sent to the client cache. In response to receiving the requested data, the client displays the data for the client.

  A data submission request has several additional steps compared to a simple client data request. First, the data is sent first to the Cache Adapter (a unique CloudCache) and then converted to a backend data cache format by the WriteCache Adapter 330. The backend data cache 340 always stores the latest data for client access, but at this stage the data is temporary and cannot be seen by the client. The data is further converted to a distributed file format 350 and saved. When the data storage in the file system 360 is successful, the cache synchronization adapter 370 retrieves the stored data and transmits it to the backend cache 380. A bit check is performed to confirm that the data matches the temporary data saved in the cache. If the check is successful, the data lock is released and the data is available to the client.

  In addition to the above, the backend system regularly updates the client data cache with the latest backend data cache. This sustained bi-directional synchronization is indicated by the thick dotted line in FIG.

  In a relational database, data for multiple users is arranged into single or partitioned multiple tables of a given instance of the database. In the current n-tier architecture, client requests are sent to the web server and then to the application server. The application server analyzes the request, requests specific data from the database, processes the request, and then sends a response to the client. In the architecture of a particular embodiment of the present invention, client requests are sent to the web server and then to the lightweight application server (LAS). The LAS analyzes the request, but instead of requesting data from the database, it sends the request to a cluster node where the data resides with some application code.

  Distributed file systems are the main medium for persistent data. All bulk data queries are specifically sent to the distributed file system and do not touch the cache. Essentially, user queries for all data into the cache are for data for a single user from the client interface. Data cell data is the end product of all data processing that occurs in a distributed file system cluster, and data from the cache is mostly used for client display and interaction purposes.

  The architectural advantage of certain embodiments of the present invention is that instead of retrieving data and returning it to the application server, the request is sent to the cache adapter and the cache adapter requests the appropriate node of the cluster where the appropriate data is present. Send.

  As shown in FIG. 7, data can be stored and retrieved from a single database instance. Although the database can be partitioned into multiple machines, the instance is always singular and the flow of requests must go through a single relational database management system instance. This is a potential single point of failure. As shown in FIG. 9, in certain embodiments of the invention, there can be a back-end infrastructure with multiple instances of a database that can communicate with clients in parallel. This design can be extended so that each client can have its own database instance that can enhance throughput and linear extensibility.

  As the number of clients increases and the size of the data begins to grow exponentially, the model cannot be maintained at some point due to the input / output limitations of a single machine that manages data flow and locking. Because the instance resides on a single machine, regardless of the power of the machine that houses the database, the model requires applications from very large data sets and consequently significant computing unit churning power. It can not withstand extremely large data loads. There are several innovative solutions such as sharding and data archiving, but almost all require manual intervention and still tend to be a single point of failure.

  In the case of system failure, there are several sophisticated solutions available for failure recovery, but this process takes a lot of time to implement and has a major impact due to long-term outages Sometimes. Data replication can be used to reduce disaster recovery time, but this involves additional cost and jeopardizes the data present in the active table relative to the archive table.

  As shown in FIG. 4, all logged-in users send a login request to the system back end. The system creates a unique persona object for the user in CloudCache on the least busy node of the cluster. Next, the system further creates an empty shell of vertical object graphs for each vertical to which the user has subscribed. There are two types of user login requests: one for the first login and one for the next login.

  Initial login requires instantiating a user profile object and then reading the same. For the first login or initial user registration, after the user persona object creation, an empty shell of the data scheme is created for each vertical that the user can subscribe to at the time of registration. At the next login, the user can register additional verticals, or disconnect them if necessary. The step of attaching the verticals to a given profile can be implemented. All of the data cell data persists in the distributed file system for permanent storage.

  At each subsequent login, in response to receiving a login request, the back end creates a user persona object, retrieves user specific data, and loads the user persona object with the unique data associated with the user object. In addition, the back end creates an empty shell of all verticals to which the user has subscribed, and then loads the data from the distributed file system into the vertical shell.

  The back end can retrieve data from the distributed file system to CloudCache. Additionally, the back end can synchronize cached data from data cells to a client database residing on the client machine.

  All users in the proposed system are identified by a unique key that creates a one-to-one relationship with the user login ID. The unique key is generated by first reversing the domain name (similar to Google creating a key identifier in BigTable), and ending with a unique user ID created by the user at registration and at first login .

  For a user with a user ID, UserID0, the key looks like the following: com: cloudcomponents: dinstance: userid0.

  In the back end, the system creates a unique data cell for every user. A data cell is a portion of the cache that the cache adapter reserves for all users. Each data cell is identified by a unique user ID associated with the user.

  FIG. 5 is a graph of a user's data cell. Within a data cell is a group of embedded data cells that hold user data for each corresponding vertical. Each cell of these embedded cells has a specific and unique structure for a specific industry vertical.

  In a traditional relational database, data is arranged in a table of a single instance of the database. A given table contains data for multiple entities. A simple example of an entity in this case would be a user. Each user is identified by a unique user ID. For a given entity, the data associated with that entity can be spread in multiple tables across the database instance. There may be hundreds of tables, which are always keyed off from the original entity ID. This allows a single table in the relational database to store data for multiple users. In order to manage data using traditional relational databases, instances exist and humans use simple partitioning of data on multiple machines and / or sharding of data on multiple machines. This requires manual intervention and the model can not be maintained in a cloud based environment due to machine input / output limitations and data location of one central location for geographically diverse users.

  The cache adapter has the ability to automatically create instances. The cache adapter is started by creating CloudCache as a single continuous cache (reserved part of multiple machines). The cache adapter creates an instance with an upper limit on its size based on the “maximum size” parameter in the configuration file. After creating the instance, the cache adapter begins the phase of loading active (logged in) user data into the instance. If the instance reaches its maximum size and cannot store any more data, the cache adapter creates a new instance. There is no limit on the number of instances that a cache adapter can create. The storage map maintains a directory listing of all instances and user IDs stored in these instances. The data stored in the cache is processing data that is ready for client consumption (client reports).

  By creating multiple instances of the database, as opposed to a single instance of the prior art, the system can spread the workload across multiple instances (nodes / machines). Once the client request is sent to the appropriate database instance, communication is limited to the client and instance. This is achieved by constructing a user ID consisting of a user ID different from the domain: database instance: a simple unique user ID in the instance. Furthermore, in every instance for every user there is an object graph for holding data about every vertical with which the user is registered.

  In relational databases, it is possible to try to create all the tables in the same instance, but as the number of tables and the size of the data grows, the model can not be maintained due to performance degradation. The main reason for the failure is physical system input / output limitations or multi-system configuration and collaboration limitations when the database is partitioned.

  The architecture of certain embodiments of the present invention removes input / output bottlenecks by creating multiple instances of the database. Creating multiple instances adds to the overall complexity of the system in terms of data consistency, which is solved by implementing a smart directory structure called StorageMap. StorageMap tracks all instances started or stopped. In addition to the list of all instances, StorageMap tracks data distribution based on each user ID in each instance. FIG. 7 shows StorageMap and data cell contents.

  Furthermore, data cells for a given user ID have only one instance of that user profile across all database instances. All transactions associated with the user profile are queued and processed sequentially within the single instance.

  As part of the registration or post-registration process, the user can subscribe to the system for one or more industrial vertical applications. Each vertical has a data layout that uniquely captures attributes associated with the industrial vertical segment. This layout at the time of subscription by the user is attached to a unique user profile. There is no limit to the number of verticals that a user can attach to the persona.

  FIG. 6 shows a cross-sectional view of the instance from different points of view. The user persona is a central object that reflects the user's identity. Various industrial vertical categories can be attached to a given user persona. Vertical can include context data such as social networking, medical records, contact relationship management, personal and business media storage, personal and business document archives, financial services, electronic games, and collaborations.

  As shown in FIG. 8, the backend synchronizes user data in the data cell with the client machine database. At each login, the user presents the user ID along with the password as a credential to the backend. Using the user ID, the back end retrieves data from the file system, creates a cache entry for the user persona object for the user in the form of data cells, and establishes a data synchronization link with the client machine. As long as all client machines have been registered in the system before, users can log in from multiple machines with the same user ID. Multiple machines can access the system with the same user ID, and when these machines are linked, their database is synchronized with the latest user data from the data cell.

  Data cell data permanently resides in the back-end distributed file system. Upon receiving a request from a client, the backend StorageMap sends a data request to the appropriate database instance containing that client's data. When a data cell is located based on a user ID, a connection (communication channel) is set to the data cell instance corresponding to that particular user ID. Also, the back end sets up and sends a security token together with the response. This security token is attached to all the following requests. If the security token is invalid (due to timeout or other reasons) or is lost, then the backend requests the client to re-login to the system.

  The architecture of certain embodiments of the present invention can be applied to social networking applications, such as Facebook. In 2008, it is speculated that the site had 1,800 servers dedicated to MySQL and 805 servers dedicated to memcache. However, since a plurality of MySQLs are sharded and the memcache instance can be executed virtually on a single server, the number of physical servers executing the infrastructure is reduced. Recently, however, there are rumors that there are more than 4000 MySQL servers and there are similar numbers dedicated to Memcache data. The number of machines represents a substantial increase from 2008, and if the growth forecast goes on schedule, a number that cannot be maintained in the future is estimated.

  MySQL, or more specifically, any relational database is not designed with the data size and throughput required for the cloud. The main drawback of any RDBMS is that it is single instance with overload related to ACID transaction compliance, buffer pool, or memory swap space locks. Although multiple instances can be attempted, applications need to be designed with data distribution across instances and multi-phase commit between multiple instances. This creates a number of hurdles such as rollback in the case of commit failure, failure recovery, etc. Embodiments of the invention include multiple instances that can communicate directly with the client rather than through a single RDBMS coordinator.

  In the architecture of certain embodiments of the present invention, there are multiple instances of the database that operate independently of each other. This is achieved by first taking the data distribution and location directory (maintained in StorageMap) outside the main database and creating data cells that confine the data for a single user within a single data cell Is done. Our solution allows the workload to be distributed across multiple instances running in parallel. The requirement for the above execution mode is only to request each single user that data is sent to a dedicated data cell for all data writes.

The following is a general table of a conventional relational database containing user data. This is a snapshot of the user table at a given point. For example, this table can contain over 5 million user IDs represented by the same number of rows of the table.
User ID First Name Last Name Zip Code
1 John Smith 10170
2 Frank Clark 10017
|
|
|
60 million mark baker 22150

If every user has at least 5 friends, a table, "friendship table", which demonstrates this relationship between the users is created according to the example.
User ID Friend_User_ID
1 6
1 5
1 4
1 3
1 2
2 1
2 9
2 8
2 7
2 6

500232657 1

  Therefore, this table requires a minimum of 500,000,000 × 5 rows to accommodate 5 friends for all users.

  If you plan to move your user ID to a specific zip code and you want to find out if you have free time on someone's calendar of your zip code user friend during a visit, that kind of query It is necessary to bring about consolidation between tables. You can optimize the query by using an index, but this is just a starting point and the system becomes more difficult to program as the object graph becomes more complex.

  In the architecture of certain embodiments of the present invention, there can be comparable tables that are 100 times larger or larger than the friendship table example, but these tables exist in the distributed file system and are only for data processing. Used for User queries never query these tables, as the data associated with all users for a single user is always present in a single data cell. In the user zip code query example, in the architecture of a particular embodiment of the present invention, the application sends a request to a data cell for that user and uses StorageMap to locate the data cell for that user. Position. Once in the data cell, the application scans a friendship table with a number of rows equal to the number of friends (a scan that is easier to process than querying a table with 500,000,000 × 5 rows). Indexing, locking in combination with data partitioning can be relatively lightly burdened, but the physical limitations of a given machine create a bottleneck. Such a model cannot be economically tolerated even with many resource allocations (multiple nodes / machines). Having filtered the line of friends for the user in the required zip code, the application can then interact with the calendar object of the friend (the filtered user). This scenario is more efficient and faster than scanning billions of rows in a traditional relational database setup. The architecture of certain embodiments of the present invention reduces the size of working data set for client requests. This is achieved by having incoming request work with a single data cell, as opposed to a table with a very large number of rows or queries that perform large table joins across partitions.

  Multiple instances provide workload distribution. Data cells further provide workload branching. A well-designed multithreaded application can take advantage of this feature to provide multifold throughput. The data cells are synchronized to the client without any help from the database controller, thereby enabling multi-channel secure communication between the back end and multiple clients simultaneously. Distributed file systems provide a robust back end for disaster recovery. The ability of the cache adapter to create and destroy memory data cells makes the system very responsive with low latency.

  The embodiments of the invention described herein are merely exemplary. Those skilled in the art can understand variations of the embodiments specifically described herein, which are intended to be within the scope of the present disclosure. Likewise, the invention is limited only by the claims. The present invention covers these modifications when they come within the scope of the claims and their equivalents.

100 cache adapter 110 web server 120 mobile device specific application client 121 HTML5 application client 130 presentation layer 131 presentation layer 140 client database 141 client database

Claims (20)

Comprising a cache adapter configured to reserve a designated portion of memory as a contiguous space in at least one node of a networked cluster of machines located on top of a distributed file system without page-based memory allocation; A distributed cache data system,
A lightweight application server controller is embedded in the cache adapter,
The designated portion of the memory comprises essentially different physical locations from the client database at the at least one node comprising data cells configured to store, retrieve and persist data from external clients. Forms a cache that exists in
The cache adapter is configured to interface to the client database at the front end of the distributed cache data system and to the distributed file system at the back end of the distributed cache data system and bidirectionally synchronized with the client database ;
It said cache adapter, in order to access the data, is configured to provide an interface for the external client in the front end of the distributed cache data system,
The cache adapter is configured to communicate bi-directionally to the external client via a web server,
A distributed cache data system, wherein the cache adapter is configured to send data access requests to the appropriate data cell of the data cell .   The distributed cache data system of claim 1, wherein the cache adapter is configured to store the data in a relational or non-relational database table format. The distributed cache data system of claim 1, wherein the cache adapter is configured to interface to the client database and the distributed file system using a Java database connectivity interface.   The distributed cache data system according to claim 1, wherein the cache adapter is configured to directly access the data present in the distributed file system without passing through the cache. The cache adapter is configured to initially check whether the data is available in the cache in response to a data request from the client database ;
If the cache contains the requested data, the cache sends the data from the cache;
If the data is not present in the cache, the cache adapter retrieves the data from the distributed file system and then sends the requested data directly to the client or the data to the client database The distributed cache data system of claim 1, wherein the data is cached prior to transmission. The cache adapter is configured to retrieve the data from the cache in a structured relationship data format and then convert the data to one of a distributed file system and an unstructured intermediate database;
The distributed cache data system of claim 1, wherein the cache adapter is further configured to convert the unstructured data from the distributed file system or the intermediate database to a cache compliant format on a return path. The distributed cache data system according to claim 1, wherein the client database comprises one of a mobile machine specific application or an HTML application client. The distributed cache data system of claim 7, wherein the client database comprises a presentation layer, a client database, and a persistent socket connection to the cache adapter.   The distributed cache data system of claim 1, wherein the cache is located in at least one node on top of the distributed file system.   The distributed cache data system of claim 1, wherein the cache adapter creates a unique instance of a cache for each user that functions as a relational database with an SQL interface for applications that interface to the cache adapter. .   The distributed cache data system according to claim 1, wherein the cache adapter exists before the distributed file system.   The distributed cache data system according to claim 1, wherein the cache is a contiguous space which spans all designated parts of the networked cluster of the machine described in a configuration file. A method for distributing cache data in a data system, comprising:
Reserving a designated portion of memory as continuous space in at least one node of a networked cluster of machines located on top of a distributed file system using a cache adapter without using page-based memory allocation;
Integrating a lightweight application server controller into the cache adapter;
Using a specified portion of the memory that includes data cells configured to store, retrieve, and persist data from external clients, a cache that resides in a physical location that is essentially different from the client database. Forming stage,
Interfacing the client database at the front end of the distributed cache data system and the distributed file system at the back end of the distributed cache data system and bidirectionally synchronizing with the client database ;
And providing an interface to the external client via the web server to access the data using the cache adapter,
Bi-directionally communicating with the external client via the web server using the cache adapter;
Sending an access request to an appropriate one of the data cells using the cache adapter;
Method including.   The method of claim 13, further comprising storing the data in a relational or non-relational database table format.   The method of claim 13, further comprising interfacing the data and the distributed file system using Java database connectivity.   The method of claim 13, further comprising directly accessing the data residing in the distributed file system without passing through the cache. A distributed cache data system,
With a cache adapter,
The cache adapter is
A lightweight application server controller embedded within the cache adapter;
Means for reserving a designated portion of memory as contiguous space for forming a cache in at least one node of a networked cluster of machines located on top of a distributed file system without using page-based memory allocation a is, specified portion of said memory stores the data from the external client, search, and Ru with a configuration data cell so as to persist, the physical location of essentially different from the client database A means of forming an existing cache;
The client database at the front end of the distributed cache data system, and means for interfacing the distributed file system at the back end of the distributed cache data system and bidirectionally synchronizing with the client database ;
Means for the dispersion provides an interface to the external client in the front end of the cache data systems, access to the data,
And means for communicating to said external client bidirectionally via the web server,
Means for sending an access request to the appropriate one of the data cells ;
A distributed cache data system comprising:   The distributed cache data system of claim 17, wherein the cache adapter further comprises means for storing the data in a relational or non-relational database table format. 18. The distributed cache data system of claim 17, wherein the cache adapter further comprises means for interfacing the client database to the distributed file system using a Java database connectivity interface.   The distributed cache data system according to claim 17, wherein said cache adapter further comprises means for directly accessing said data present in said distributed file system without passing through said cache.

Images