Ingres дерекқоры: даму тарихы мен технологиясы

Database software
the technical development of the database

Ingres Database (/ɪ//ŋ/'/ɡ//r//ɛ//s/ ingGRESS') is a proprietary SQL relational database management system intended to support large commercial and government applications. Actian Corporation, which announced April 2018 that it is being acquired by HCL Technologies, controls the development of Ingres and makes certified binaries available for download, as well as providing worldwide support. There was an open source release of Ingres but it is no longer available for download from Actian. However, there is a version of the sourcecode still available on GitHub. In its early years, Ingres was an important milestone in the history of database development. Ingres began as a research project at UC Berkeley, starting in the early 1970s and ending in 1985. During this time Ingres remained largely similar to IBM's seminal System R in concept; it differed in more permissive licensing of source code, in being based largely on DEC machines, both under
UNIX and VAX/VMS, and in providing QUEL as a query language instead of SQL. QUEL was considered at the time to run truer to Edgar F. Codd's relational algebra (especially concerning composability), but SQL was easier to parse and less intimidating for those without a formal background in mathematics. When ANSI preferred SQL over QUEL as part of the 1986 SQL standard (SQL 86), Ingres became less competitive against rival products such as Oracle until future Ingres versions also provided SQL. Many companies spun off of the original Ingres technology, including Actian itself, originally known as Relational Technology Inc., and the NonStop SQL database originally developed by Tandem Computers but now offered by Hewlett Packard Enterprise.

Ingres began as a research project at the University of California, Berkeley, starting in the early 1970s and ending in 1985. Postgres (Post Ingres), a project which started in the mid 1980s, later evolved into PostgreSQL. It is ACID compatible and is fully transactional (including all DDL statements) and is part of the Lisog open source stack initiative.

In 1973 when the System R project was getting started at IBM, the research team released a series of papers describing the system they were building. They had already raised money for researching a geographic database system for Berkeley's economics group, which they called Ingres, for INteractive Graphics REtrieval System. They decided to use this money to fund their relational project instead, and used this as a seed for a new and much larger project. They decided to re use the original project name, and the new project became University INGRES. as they were already funding database research elsewhere. Stonebraker then introduced his idea to other agencies, and, with help from his colleagues he eventually obtained modest support from the NSF and three military agencies: the Air Force Office of Scientific Research, the Army Research Office, and the Navy Electronic Systems Command. Thus funded, Ingres was developed during the mid 1970s by a rotating team of students and staff. Ingres went through an evolution similar to that of System R, with an early prototype in 1974 followed by major revisions to make the code maintainable. Ingres was then disseminated to a small user community, and project members rewrote the prototype repeatedly to incorporate accumulated experience, feedback from users, and new ideas. The research project ended in 1985. primarily to universities. Many students from U. C. Berkeley and other universities who used the Ingres source code worked on various commercial database software systems. Berkeley students Jerry Held and later Karel Youseffi moved to Tandem Computers, where they built a database system that evolved into NonStop SQL. The Tandem database system was a re implementation of the Ingres technology. It evolved into a system that ran effectively on parallel computers; that is, it included functionality for distributed data, distributed execution, and distributed transactions (the last being fairly difficult). Components of the system were first released in the late 1970s. By 1989, the system could run queries in parallel and the product became fairly famous for being one of the few systems that scales almost linearly with the number of processors in the machine: adding a second CPU to an existing NonStop SQL server will almost exactly double its performance. Tandem was later purchased by Compaq, which started a re write in 2000, and now the product is at Hewlett Packard Enterprise. In the early 1980s, Ingres competed head to head with Oracle. The two products were widely regarded as the leading hardware independent relational database implementations; they had comparable functionality, performance, market share, and pricing, and many commentators considered Ingres to be a (perhaps marginally) superior product. From around 1985, however, Ingres steadily lost market share. One reason was Oracle's aggressive marketing; another was the increasing recognition of SQL as the preferred relational query language. Ingres originally had provided a different language, QUEL, and the conversion to SQL (delivered in Ingres version 6) took about three years, losing valuable time in the race. Robert Epstein, the chief programmer on the project while he was at Berkeley, formed Britton Lee, Inc. along with other students from the Ingres Project, Paula Hawthorn and Michael Ubell; they were joined later by Eric Allman. Later, Epstein founded Sybase. Sybase had been the #2 product (behind Oracle) for some time through the 1980s and into the 1990s, before Informix came "out of nowhere" and took over in 1997. Sybase's product line had also been licensed to Microsoft in 1992, who rebranded it as Microsoft SQL Server. This relationship soured in the late 1990s, and today SQL Server outsells Sybase by a wide margin.

Several companies used the Ingres source code to produce products. The most successful was a company named Relational Technology, Inc. (RTI), founded in 1980 by Stonebraker and Wong, and another Berkeley professor, Lawrence A. Rowe. RTI was renamed Ingres Corporation in the late 1980s. The company ported the code to DEC VAX/VMS, which was the commercial operating system for DEC VAX computers. They also developed a collection of front end tools for creating and manipulating databases (e. g., reporterwriters, forms entry and update, etc.) and application development tools. Over time, much of the source was rewritten to add functionality (for example, multiple statement transactions, SQL, B tree access method, date/time datatypes, etc.) and improve performance (for example, compiled queries, multithreaded server). The company was purchased by ASK Corporation in November 1990. The founders left the company over the next several months.

On September 22, 2011, Ingres Corporation became Actian Corporation, focusing on data management and integration technologies, including Vectorwise/Vector, Btrieve/Pervasive PSQL/Zen, OpenROAD and the Ingres database. Actian was acquired by HCL Technologies and Sumeru Equity Partners for $330 million. In 2021, HCL Technologies became the sole owner of Actian, which became the Data and Analytics division of HCLSoftware.

Release General availability End of Enterprise Support End of Extended Support End of Obsolescence Support Notes September, 1991 30 Sep 01 31 Dec 08 January, 1996 September 31, 2000 31 Dec 08 It integrated an unstructured data type (audio, video, blob), temporary tables (in memory) and the Visual DBA administration suite February, 1999 1 May 05 31 Dec 08 31 Dec 13 Line locking, variable page size, massive loading, server level replication (the old system of capturing data modifications by rules has been abandoned). July, 2001 31 Dec 07 31 Dec 12 31 Dec 17 First Ingres version for Linux. This version also made it possible to fully exploit 64 bit architectures. Introduction of the JDBC driver. May, 2002 31 Dec 09 31 Dec 14 31 Dec 19 First enterprise class DBMS to fully exploit the 64 bit architecture under Linux. Support for XML, Unicode and improvement and splitting of administration tools (Ingres Visual Manager, Ingres Performance Monitor, Ingres Import Assistant, Ingres Visual SQL, etc). November, 2004 31 Dec 07 Computer Associates makes Ingres R3 open source under the CATOSL license. Support for partitioned tables, parallel query and a new data optimization algorithm. March, 2007 31 Dec 11 31 Dec 16 31 Dec 21 Entry of Ingres into the world of open source products (under GPL license). Stability, further enhanced functionality and performance, ease of installation. Release of IceBreaker BI. November, 2008 31 Dec 15 31 Dec 20 31 Dec 25 Improved support for JDBC, Net and PHP in terms of performance. Log shipping features and UTF 8 support. September, 2010 31 Dec 16 31 Dec 21 31 Dec 26 The release contains a number of major enhancements that minimize application development time when migrating applications from other databases to Ingres. New features include support for multi version concurrency control (MVCC), high performing batched statement execution, full scalar subquery support, support for identifiers up to 256 characters long, and column level data encryption. The release supports an automated, seamless migration from earlier versions of Ingres. May, 2012 31 May 17 31 May 22 31 May 27 Includes comprehensive spatial support, allowing to extend location based data through spatial aware applications, avoiding complex add ons and integrations with other databases, and no need to pay extra to access geospatial features. April, 2014 31 May 18 31 May 23 31 May 28 4 Sep 14 1 Sep 19 1 Sep 22 1 Sep 25 New features include 2 D, 3 D and 4 D Spatial Data Types, Remote GCA, UTF 8 Transliteration, DBMS Level Authentication, IPV4 and IPV6 Data Types and Functions and Per query Parallelism Level. Users can also take their first steps into Big Data Analytics by applying the new Windowing functions to their existing transactional data. 31 Mar 17 31 May 23 31 May 27 31 May 32 Ingres 11 includes two significant additions for application integration and monitoring. IngresConnect provides an end to end solution for designing, deploying and managing data integration, and the Actian Enterprise Monitoring Appliance (EMA) can use Nagios compatible plug ins now in Ingres to monitor Ingres environments. Ingres 11 also contains many new geospatial, performance, ease of use and security features. A few of the highlights are: ArcGIS plug in, query optimizer reuse heuristics, automatic log file rotation, IANA timezones, Y2K38 fix, blob encryption and AES password encryption. 31 Mar 17 31 May 23 31 May 27 6 May 22 31 Dec 25 6 May 22 31 May 27 31 May 32 31 May 37 Ingres 11.2 contains many new management, development and security features. Ingres 11.2 introduces Workload Management Phase 1, JSON Support, Data Masking for sensitive data, Partition Management, Pivot Tables, and Encryption Initialization Vectors, among other changes. Ingres 11.2 also contains a development release of SQL UDFs with development only support. With the announcement of Ingres 9.1 (Ingres 2006 release 2) on the VMS platform the support dates for VMS will now follow the normal Actian release dates as listed above with the following exceptions; dropping of the Alpha VMS 2.0 release has been announced and Enterprise Support ended on December 31, 2009 with Extended Support offered through December 31, 2013. All support for VAX VMS ended on December 31, 2008.

Ingres is a single node relational database management system, and therefore it is "Share Everything".

Ingres is a disk oriented DBMS, and by default employ the n ary storage model (NSM), also known as a row store. However, Actian has incorporated columnar storage into its latest version of Ingres (Actian X) to improve its performance on OLAP tasks. Actian X has two storage engines, the traditional Ingres and X100, the same engine from Actian Vector. Although it is currently branded as the "Actian X Hybrid Database", the term "Hybrid" refers to its capability of performing both OLTP and OLAP tasks by employing a hybrid storage model (i. e. both row and column), not that it has a hybrid storage architecture. Regarding the storage organization, Ingres supports Heap, Hash, ISAM and B tree.

Ingres chooses ISAM (Index Sequential Access Method) as the index data structure by default, but also offers B+ Tree, Hash Table, and R Tree as options. On Actian X, there is also two other options available only for X100 tables:
X100 IX: Default, creates a primary (clustered) index. Only one primary index per table is allowed. X100 SI: Creates a secondary index on additional columns in an X100 table. Can also be specified as VWSI. Secondary indexes are not supported for partitioned tables.

Ingres uses Multi version Concurrency Control (MVCC), Deterministic Concurrency Control, and Two Phase Locking (Deadlock Detection).

Ingres supports four isolation levels, from favoring consistency to maximizing concurrency: Serializable, Repeatable Read, Read Committed. and Read Uncommitted, Serializable is the default isolation level and it provides the strongest consistency guarantee.

Ingres supports joins with hash join, sort merge join, and nested loop join algorithms. The query optimizer determines which type of join algorithm to use based on its analysis of the query. Nested loop joins are most often seen on disjoint queries, where correlation variables and table names are arbitrarily used in random order. When there are no restrictions on either table in the join clause, and the rows being joined are spatially continuous, then the query optimizer is likely to choose sort merge join or hash join.

Ingres can be installed as a client (Client Installation) or as a server (Server Installation), the client does not have a database associated with it, but it allows you to access the database created in the server installation. A typical site installs the Ingres client for workers on the computers that will interact with the Ingres server at the core of the site. Note that the expression "instance" is synonymous with "installation". An installation can be thought of as a collection of server processes, shared memory, and semaphores for inter process communication, as well as disk files used for transaction processing and recovery in the event of a host or installation failure.

An installation is often named by its installation ID. This identifier consists of two case sensitive characters, starting with a letter. The default is II. The installation ID is used to calculate which ports the Ingres servers will listen on. For example, "II" indicates that the servers are listening on port 21064 and 7 ports after it. Any host (machine or virtual machine) can have multiple installations of Ingres, but each installation must have a unique identifier to ensure that clients and components interact with the correct installation. One installation can use multiple installation IDs. A classic example is when you need to run more than 8 processes on the server. Also, while Ingres database servers (iidbms) and Ingres communication servers (iigcc) conventionally use the same installation ID, there is no requirement to do so.

Some important paths must be assigned at the location where the installation was created. The paths will not change without reinstallation, so you should take care to choose them. The paths are shown in the following table. Note that the "II " prefix does not indicate that these paths are for the "II" installation. Each installation, regardless of its ID, will have its own set of these variables. Name PurposeII SYSTEMSetup binary files, utilities, text files used for configuration, etc. II DATABASELocation of installation master data. II CHECKPOINTDatabase backup location. II JOURNALLocation where database installation transactions are logged. The logs use the recovery system to provide point of failure recovery. Can be used for audit purposes. II DUMPLocation where "dump" installation files are stored. They can be generated during "online" database backups and [ what? ] to restore. II WORKUsed to store work files generated by the server when querying the database.

An Ingres installation (or instance) can support multiple databases, each owned by any user known to the installation. The installation allows multiple databases to be accessed at the same time. The number of databases is a configurable value. Note that this simply limits the number of databases available at any one time and many more databases can be created. When creating an Ingres server installation, the databases "iidbdb" and "imadb" will be created, owned by the user "$ingres". The iidbdb database, also known as the "Master Catalog database", contains many special tables to manage the installation itself. The imadb (Management Architecture database) database also includes registered objects used to manage the installation. Of particular note is that databases are not pre sized. Each database in the installation is allowed to grow in size as much as the free disk space allows.

The Postgres project was started in the mid 1980s to address limitations of existing database management implementations of the relational model. Primary among these was their inability to let the user define new domains (or "types") which are combinations of simpler domains (see relational model for an explanation of the term "domain"). The project explored other ideas including the incorporation of write once media (e. g., optical disks), the use of massive storage (e. g., never delete data), inferencing, and object oriented data models. The implementation also experimented with new interfaces between the database and application programs (e. g., "portals", which are sometimes referred to as "fat cursors"). The resulting project, named "Postgres", aimed at introducing the minimum number of features needed to add complete types support. These included the ability to define types, but also the ability to fully describe relationships – which up until this time had been widely used but maintained entirely by the user. In Postgres, the database "understood" relationships, and could retrieve information in related tables in a natural way using rules. In the 1990s, Stonebraker started a new company to commercialize Postgres, under the name Illustra. The company and technology were later purchased by Informix Corporation.