SolarCloud Rapid Data Loggingfrom a Solar Power Plant

Transcription

1 SolarCloud Rapid Data Loggingfrom a Solar Power Plant AUTHOR: TEODOR TALOV COP 4908 Independent Study Instructor: Janusz Zalewski Florida Gulf Coast University Fort Myers, FL July25, 2013 Final Draft SolarCloud Rapid Data Logging 1

2 1. Introduction The objective of this project is to provide an overview of a non relational database using MongoDB as an example, compare its performance with MySQL, and test its operations for data storage from the solar panel node, as a case study. The rest of the document is structured as follows: Section 2 describes the principles of storing data in MongoDB; Section 3 presents the comparison methodology, and Section 4 describes a case study of the Solar Plant. Section 5 describes some comparison in performance between MongoDB and MySQL. Both databases are compared with different length of records as well as different number of records 10, 100, 1000, respectively. Finally, Section 6 outlinessome conclusions. SolarCloud Rapid Data Logging 2

3 2. MongoDB 2.1. Overview of MongoDB MongoDB is a shared nothing, document oriented database management system. Unlike relational database systems, which store all data in tables defined by a schema, MongoDB stores data in schema less JSON documents (Fig 1). Users perform queries against the database using procedural API calls, rather than using a declarative language like SQL. It combines the ability to scale out with many of the post powerful features of relational databases, such as secondary indexes, range queries, and sorting. MongoDB is also incredibly featureful: it has tons of useful features such as built in support for MapReduce style aggregation and geospatial indexes. Fig 1. Example of MongoDB document structure Mongo is a document oriented database, not a relational one. The primary reason for moving away from the relational model is to make scaling out easier, but there are some other advantages as well. In a relational database scaling out becomes challenging once the cluster reaches capacity and adding more storage becomes necessary. Additional complexity is introduced by adding more servers because in a relational database is not able to determine how to interact with multiple servers. Most common scenario is masterslave replication, which works very well for applications relaying heavily on Read operations, but it is not very effective for Write heavy applications, simply because there SolarCloud Rapid Data Logging 3

4 must be only one node, the master node, containing the complete database, which gets copied over to all slave nodes. In contrast, MongoDB, and most NoSQL databases for that matter, come with built in scalability. Specifically, once capacity is reached, more servers can be added to the cluster, but MongoDB will handle how they are used automatically. It can balance data and load across a cluster, redistributing documents automatically. When they need more capacity, they can just add new machines to the cluster and let the database figure out how to organize everything. The basic idea is to replace the concept of a row with more flexible model, the document. By allowing embedded documents and arrays, the document oriented approach makes it possible to represent complex hierarchical relationships with a single record. This fits very naturally into the way developers in modern object oriented languages think about their data. MongoDB is also schema free: a document s keys are not predefined or fixed in any way. Being schema free does not mean that there is no schema to the database. To the contrary, there is schema to the database, but it is not strictly enforced by MongoDB. Without a schema to change, massive data migrations are usually unnecessary. New or missing keys can be dealt with at the application level, instead of forcing all data to have the same shape. This gives developers a lot of flexibility in how they work with evolving data models. MongoDB was designed from the beginning to scale out. [4] MongoDB also provides most if not all features that a relational databases provides such as indexing, stored procedures, aggregation, etc. Specifically, indexing supported by MongoDB is generic secondary indexes, allowing a variety of fast queries and it provides unique, compound, and geospatial indexing capabilities as well. Furthermore, the stored SolarCloud Rapid Data Logging 4

5 procedures that MongoDB supports are simply JavaScript functions. For aggregation MongoDB supports MapReduce amongst many other features such as aggregate, group, etc. Concerning security MongoDB has provided multiple mechanisms such as, Access Control and Network Security. Furthermore, 10gen [3] provides a security guide which takes a Defense in Depth approach to securing MongoDB deployments and addresses a number of different methods for managing risk and reducing risk exposure.the intent of a Defense In Depth approach is to ensure there are no exploitable points of failure in the deployment that could allow an intruder or untrusted party to access the data stored in the MongoDB database. The easiest and most effective way to reduce the risk of exploitation is to run MongoDB in a trusted environment, limit access, follow a system of least privilege, and follow best development and deployment practices Installation Guide to MongoDB [3] To install MongoDB the following steps have to be followed: Add 10gen package to source.list.d by running the following commands: sudo apt-cache search mongodb mongodb mongodb-clients mongodb-dev mongodb-server Add the following line to /etc/apt/sources.list.d/mongo.list: deb dist 10gen SolarCloud Rapid Data Logging 5

6 Note: If the file does not exist, create it Add GPG Key in order to verify the authenticity of the MongoDB repository by running the following command: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB Update Ubuntu by running the following command: sudo apt-get update Install MongoDB by running the following command: sudo apt-get install mongodb-10gen Verify that MongoDB is running by executing the following command: mongo If MongoDB is running, the screen is shown on Fig. 2 SolarCloud Rapid Data Logging 6

7 Fig. 2 MongoDB Shell The application is hosted on the Key West server, which has Ubuntu 12 installed as operating system. The serverr can be accessed using the following credentials: or keywest.cs.fgcu.edu/ username: keywest password: same as VMWARE host password Note: keywest user has administrative privileges (sudoer) SolarCloud Rapid Data Logging 7

8 3. MongoDB vs. MySQL comparison methodology General concepts have to be evaluated in both MongoDB and MySQL. Additionally, features in MongoDB need to be compared to their respective features in MySQL and then their performance evaluated. Performance is evaluated by running heavy database queries, , , records respectively, for each of the features outlined below. Finally, operators and syntax such as > and $gthave to be compared in both MySQL and MongoDB 3.1. General Concepts Database Database is an organized collection of data. Both MySQL and MongoDB use databases to store data. MySQL MySQL is an open source relational database management system. Information in a MySQL database is stored in the form of related tables. MySQL does have multiple storage engines such as MyISAM and InnoDB. MongoDB A physical container for collections. Each database gets its own set of files on the file system. A single MongoDB server typically servers multiple databases. MongoDB does not support different storage engines Table vs. Collection MySQL Since MySQL is relational database management system (RDMS) all the data is stored in tables, which are organized according to the relation model. The relational model for database management is a database model based on first order predicate logic, first formulated and proposed in 1969 by Edgar F. Codd. In the relational model of SolarCloud Rapid Data Logging 8

9 a database, all data is represented in terms of tuples, grouped into relations. A database organized in terms of the relational model is a relational database. MongoDB Unlike MySQL MongoDB does not use tables, but it uses COLLECTIONS. Collections are groupings of BSON documents (A serialization format used to store documents and make remote procedure calls in MongoDB. BSON is a portmanteau of the words binary and JSON. Think of BSON as a binary representation of JSON (JavaScript Object Notation) documents). Collections do not enforce a schema, but they are otherwise mostly analogous to RDBMS tables. The documents within a collection may not need the exact same set of fields, but typically all documents in a collection have a similar or related purpose for an application. All collections exist within a single database. The namespace within a database for collections are flat Row vs. Document MySQL Since MySQL is a relational databases, it uses rows. In the context of a relational database, a row also called a record or tuple represents a single, implicitly structured data item in a table. In simple terms, a database table can be thought of as consisting of rows and columns or fields. Each row in a table represents a set of related data, and every row in the table has the same structure. For example, in a table that represents companies, each row would represent a single company. Columns might represent things like company name, company street address, whether the company is publicly held, its VAT number, etc.. In a table that represents the association of employees with departments, each row would associate one employee with one department. [5] SolarCloud Rapid Data Logging 9

10 MongoDB stores structured data as JSON like documents, using dynamic schemas (called BSON), rather than predefined schemas. In MongoDB, an element of data is called a document, and documents are stored in collections. One collection may have any number of documents. [3] Column vs. Field MySQL MySQL uses columns. In the context of a relational database table, a column is a set of data values of a particular simple type, one for each row of the table. The columns provide the structure according to which the rows are composed. [5] MongoDB On the other hand MongoDB uses fields. A name value pair in a document. Documents have zero or more fields. Fields are analogous to columns in relational databases. [3] Indexes Index is a data structure that improves the speed of data retrieval operations on a database table at the cost of slower writes and the use of more storage space. Indexes can be created using one or more columns of a database table, providing the basis for both rapid random lookups and efficient access of ordered records. Both MySQL and MongoDB index data in the same way Table joins vs. embedded documents and linking Traditional SQL databases use table joins. A table join combines records from two or more tables in a database. It creates a set that can be saved as a table or used as it is. A JOIN is a means for combining fields from two tables by using values common to each.mysql resolves all joins using a single sweep multi join method. This means that MySQL reads a row from the first table, and then finds a matching row in the second SolarCloud Rapid Data Logging 10

11 table, the third table, and so on. When all tables are processed, MySQL outputs the selected columns and backtracks through the table list until a table is found for which there are more matching rows. The next row is read from this table and the process continues with the next table.mongodb does not support joins. In MongoDB some data is denormalized, or stored with related data in documents to remove the need for joins. However, in some cases it makes sense to store related information in separate documents, typically in different collections or databases Primary key The PRIMARY KEY constraint uniquely identifies each record in a database table.a record s unique, immutable identifier. In anmysql, the primary key is typically an integer stored in each row s id field. In MongoDB, the _id field holds a document s primary key which is usually a BSON ObjectId Aggregation Aggregate functions perform a calculation on a set of values and return a single value. The data that needed is not always stored in the tables. However, it can obtain by performing the calculations of the stored data when you select it. Except for COUNT, aggregate functions ignore null values. Aggregate functions are frequently used with the GROUP BY clause of the SELECT statement. Both MongoDB and MySQL use aggregation similarly. However, MongoDB performs aggregation via its aggregation framework Programming Features This section is a side by side comparison of MySQL versus MongoDB. It compares their SolarCloud Rapid Data Logging 11

12 functions such as Select vs. Find, Update, Delete, and other operations. It also provides syntax comparison for both database types MySQL and MongoDB Select vs. Find operations MySQL the SQL select statement returns a result set of records from one or more tables [5]. A select query looks like: SELECT * FROM users MongoDB uses find in order to retrieve data sets by given criteria. A find statement looks like: db.users.find() Insert operations MySQL uses its insert statement in order to add rows to a table. An insert statement as follows: INSERT INTO users(user_id, age, status) VALUES ("bcd001", 45, "A") MongoDB uses its insert statement in order to insert a record to a document. An insert statement looks like this: db.users.insert( { user_id: "bcd001", age: 45, status: "A } ) Update operations SolarCloud Rapid Data Logging 12

13 MySQL uses its update statement in order to update existing records in a table. An update statement looks like this: UPDATE users SET status = "C" WHERE age > 25 MongoDB uses its update statement in order to update existing records in a document. An update statement looks like this: db.users.update({ age: { $gt: 25 }},{$set:{ status: "C" }},{ multi: true }) Delete operations MySQL uses its delete statement in order to delete existing records from a table. An delete statement looks like this: DELETE FROM users WHERE status = "D" MongoDB uses its delete statement in order to delete existing records from a document. An delete statement looks like this: db.users.remove( { status: "D" } ) 3.3. Operators Logical Operator AND MySQL logical AND operator compares two expressions and returns true if both of the expressions are true. In MongoDB a logical AND joins two clauses and returns all documents that match the conditions of two clauses Logical Operator OR MySQL OR operator compares two expressions and returns TRUE if either of the SolarCloud Rapid Data Logging 13

14 expressions is TRUE. In MongoDB a logical ORoperator, joins query clauses with all documents that match the conditions of either clause Logical Operator NOT MySQL NOT operator reverses or negates the input. In MongoDB NOT inverts the effect of a query expression and returns documents that do notmatch the query expression 3.4. Essential Functions Order By vs. Sort In MySQL the SQL ORDER BY clause allows sorting records in a result set. The SQL ORDER BY clause can only be used in SQL SELECT statements. In MongoDB sort() is returns a cursor with documents sorted according to a sort specification Where In MySQL SQL WHERE clause allows you to filter the results from an SQL statement SQL SELECT statement, SQL INSERT statement, SQL UPDATE statement, or SQL DELETE statement. In MongoDB $where returns that match documents that satisfy a JavaScript expression Max In MySQL MAXfunction returns the maximum value of an expression. In MongoDB max() specifies a minimum exclusive upper limit for the index to use in a query SolarCloud Rapid Data Logging 14

15 Min In MySQL MINfunction returns the maximum value of an expression. In MongoDB min() specifies a minimum exclusive upper limit for the index to use in a query SolarCloud Rapid Data Logging 15

16 4. Case Study 4.1. Overview FGCU s Solar Plant (Fig. 3) takes up 760 acres of its campus, which makes it the second larges solar installation located in a University campus in the U.S. [1]. The plant began its operations in 2009 and it is expected that the 2 megawatt Solar Plant will generate 15% of the electricity that the University consumes [2]. Fig 3: Solar Plant Eagle View Additionally, the Solar Plant includes a separate small site where different panels can be tested and demonstrated (Fig. 4). SolarCloud Rapid Data Logging 16

17 Fig 4. Experimental Solar Plant at FGCU The smaller installation is very safe and convenient for experiments, since it does not interfere with the main solar plant, but provides the same exact configuration as the main plant. This is, indeed, the site where all upcoming experiments can be conducted [6]. 4.2 Problem Description The power current generated by the Solar Plant is not steady, thus energy fluctuations occur. It is mandated by the State of Florida that power current must be steady at all times. Becausee of its mandate, the Solar Plant cannot contribute power to the power grid without installing additional hardware (back up that problem, data must be analyzed at much higher frequency than it is generators), which willl kick in whenever the current is not steady. In order to solve currently supported by the existing system. The current system has the ability to acquire data from the Solar Plant every 1 minute. However, the desired frequency for data analyses is every 1 second. Therefore, a software application has to be developed that will acquire data with the SolarCloud Rapid Data Logging 17

18 desired frequency. Fig. 5Solar Plant data acquisition diagram The primary objective of the project is to acquire data from the experimental solar plant in 1 second intervals and record these data into a database. Furthermore, the data have to available on the Internet and accessible upon successful authentication. The proposed system outlined in Fig. 5, acquires data every second.the SolarCloud softwareresiding on the webserver sends a request to the CR 1000 data logger via its Ethernet Interface NL 120.As a response the CR 1000 sends back a JSON or XML object containing a data structure with measurement results, which is stored in a database by SolarCloud software. The end user (public client) will be able to generate reports based on the data that are already stored in the database. 4.3Project Objective and Technology Data Logger SolarCloud Rapid Data Logging 18

19 To acquire data from the solar plant every second as opposed to every minute as in current system. For data acquisition from the Solar Plant a Campbell Scientific CR Data logger (Fig. 6) will be used [7]. Fig 6: Campbell Scientific CR 1000 Data logger The CR1000's module acquires measurement from sensors, drives direct communications and telecommunications, reduces amount of data, controls external devices, and stores data and programs in on board, non volatile by the sealed, stainless steel canister. A battery backed clock assures storage. The electronics are shielded from RF interference and glitch protected accurate timekeeping. The module can simultaneously provide measurement and communication functions[7]. Campbell Scientific CR 1000 Data logger has a built in Application Programming Interface (API) which allows third party applications to authenticate, request data, and receive a response in an XML or JSON format. In order to allow the CR1000 data logger to communicate over a local network or a dedicated Internet connection via TCP/IP a NL 120 Ethernet (Fig. 7) interfacee is used [6]. The NL120 uses a 10baseT Ethernet straight through cable when the cable is run from a hub to the NL120. A 10baseT Ethernet crossover cable is used if the cable is run directly from the computer to the SolarCloud Rapid Data Logging 19

20 NL120. For cable lengths longer than 9 feet, either a shielded 10baseT Ethernet cable or the surge protector needs to be used [6]. Fig 7: NL 120 Ethernet interface Running the App (Fig. 13). Usage of available channels of CR 1000 data logger are shown on Fig 8. There are 5 channels currently in use as follows: Channel 1: System Volts Channel 2: Shunt Volts Channel 3: Shunt Tem Sensor Channel 4: Panel Temperature Sensor Channel 5: Tilt Sensor SolarCloud Rapid Data Logging 20

21 Fig. 8 Proposed use of data channels Configuration of CR 1000 data logger. To interface with the CR 1000 Campbell Scientific s PC200W supplied software (Fig. 9) must be used. SolarCloud Rapid Data Logging 21

22 Fig. 9 PC200W user interface The data logger must be connected to a Microsoft Windows PC via serial cable via its serial port RS 232 (shown in Fig 10). Fig 10 Port RS 232 of the data logger. After the data logger is successfully connected with the cable and the software to the PC, the program found in Appendix A must be uploaded to the data logger. This will reconfigure the data logger with the appropriate tables. In this Case Study the parameters are shown in Table 1. Each row corresponds to a channel of the Data Logger. Voltage1 Voltage2 Voltage2 Voltage4 Voltage5 Table 1. Table used by the Data Logger in this Case Study. Additionally, a static IP must be assigned to the data logger in order for other devices to be able to request data from it. This is done via the Device Configuration Utility within the PC200Wprogram as shown on Fig 11 below. SolarCloud Rapid Data Logging 22

23 Fig 11. Device Configurationn Utility by Campbell Scientific Assign the following measurements to each channel: Bind Average Voltage to Channel 1 (more to come heree once we install the data logger) Database platform SolarCloud The software application has been developed which acquires the data from the Solar Plant at 1 second intervals and records the readings in a database. Finally, the data have to be presented SolarCloud Rapid Data Logging 23

24 to the end user. The following technology stack shown in Fig 12 is suitable for use in this case: Solar Cloud Application MongoDB NodeJS Linux Fig 12. Technology stack Installation of the Server Environment The following technologies have to be installed on the server in this order (admin privileges required) Operating System: Ubuntu 12.x [6] Installation notes: Isntall Ubuntu using a LiveCD with the following network configuration: auto eth0 face eth0 inet static address netmask network broadcast gateway dnssearch cs.fgcu.edu dns-nameservers SolarCloud Rapid Data Logging 24

25 Web Server: Apache 2.2x [6] Run the following commands to install Apache sudo apt-get install tasksel sudotasksel install lamp-server Database: MongoDB [6] See section 2 for installation notes: Back end technologies: NodeJS [6] Run the following commands in order to install NodeJS sudo apt-get install python-software-properties python g++ make sudo add-apt-repository ppa:chris-lea/node.js sudo apt-get update sudo apt-get install nodejs Version control: Git Installation notes: Run the following command in order to install Git sudo apt-get install git SolarCloud Installation Solar Cloud software has been developed in the Spring 2013 project [6]. The general design is SolarCloud Rapid Data Logging 25

26 shown in Fig 13. Execute the following stepss in order to install SolarCloud Createe a solarcolud directory under /etc/www by running the following command sudomkdir /etc/www/solarcloud Navigate to the SolarCloud directory by running the following command cd /etc/www/solarcloud Clone the GitHubrepositorygit@github.com:teodortalov/data- acquisition-nodejs-mongodb.gitby running the following command sudogit clone git@github.com:teodortalov/data-acquisition- nodejs-mongodb.git.. If port 22 is blocked the repostiroy could be cloned via HTTPS by running the following command: git clone nodejs-mongodb.git. SolarCloud Rapid Data Logging 26

27 Install Express Framework by running the following command: sudonpm install SolarCloud Startt In order to start the Fetcher run the following commands: cd /etc/www/solarcloud node fetcher In order to start the App, run the following commands: cd /etc/www/solarcloud node app(shown on Fig 12) 4.4 Troubleshooting There are multiple known issues with the current configuration. All known issues are listed below as well as suggested resolutions for each of them Data logger does not respond with the expected JSON data structure. Example of the issue is shown on Fig 14 Fig 14. Incorrect response from data logger SolarCloud Rapid Data Logging 27

28 This issue might be a result of the internal memory of the data logger being full. Suggested resolution is reconfiguring the data logger to its initial state using the program included in Appendix A. If when connecting to MongoDB the following error is thrown: JavaScript execution failed: Error: couldn't connect to server :27017 at src/mongo/shell/mongo.js:l112 exception: connect failed run the following command to resolve the issue: sudorm /var/lib/mongodb/mongod.lock SolarCloud Rapid Data Logging 28

29 5. Experiements Experiments are ran on two separate servers, a development server and production server (Key West server). Both have Ubuntu 12.4 with PHP 5.4, MySQL 5.5 and MongoDB 2.4. Some experiementation was conducted with READ and WRITE operations for both MySQL and MongoDB. Also experimentation was done with the following number of records: 10, 100, 1 000, Each experiment is ran with two different record lenghts, 10 characters and 100 characters. Diagram of server infrastructure for both MongoDB and MySQL is shown on Fig 15 Ubuntu Ubuntu Apache webserver Apache webserver PHP PHP MySQL MongoDB Fig 15 Server Infrastructure for MySQL and MongoDB PHP was used as a mid ware and InnoDB was used as MySQL s storage engine. The experiments were run on two servers with indentical configuration but different server resources. Server 1 Processor 2.4GHz and RAM: 16.00GB Server 2 (Key West) Processor 1.98GHz and RAM: 1.96GB The resutls from WRITE are shown on below: SolarCloud Rapid Data Logging 29

30 Server 1 10 characters record lenght: WRITE operations Number of records MongoDB execution time (sec) MySQL execution time (sec) Table 2 Timing WRITE operations of Server 1 with 10 characters record lenght READ operations Number of records MongoDB execution time (sec) MySQL execution time(sec) Table 3 Timing of READ operationsof Server 2 with 10 characters record lenght SolarCloud Rapid Data Logging 30

31 100 characters record lenght: WRITE operations Number of records MongoDB execution time (sec) MySQL execution time (sec) Table 4 Timing WRITE operations of Server 1 with 100 characters record lenght READ operations Number of records MongoDB execution time (sec) MySQL execution time(sec) Table 5 Timing of READ operations of Server 2 with 100 characters record lenght SolarCloud Rapid Data Logging 31

32 Server 2 10 characters record lenght: WRITE operations Number of records MongoDB execution time (sec) MySQL execution time (sec) Table 2 Timing WRITE operations of Server 1 with 10 characters record lenght READ operations Number of records MongoDB execution time (sec) MySQL execution time(sec) Table 3 Timing of READ operations of Server 2 with 10 characters record lenght SolarCloud Rapid Data Logging 32

33 100 characters record lenght: WRITE operations Number of records MongoDB execution time (sec) MySQL execution time (sec) Table 4 Timing WRITE operations of Server 1 with 100 characters record lenght READ operations Number of records MongoDB execution time (sec) MySQL execution time(sec) Table 5 Timing of READ operations of Server 2 with 100 characters record lenght Interpreatation of the resutls: Clearly MongoDB outperfomed MySQL by far in WRITE SolarCloud Rapid Data Logging 33

34 operations, however MySQL slightly outperformed MongoDB in READ operations.results are somewhat inconsistent which is probalby due to other processes running on the operating system. However, MySQL performance could also be affected by the storage engine used. In the experiments InnoDB is used as a storage engine, but other storage engines are available such as MyISAM, ARCHIVE, BLACKHOLE, etc. Each storage engine would perform differently because it provides different features. The code used in the experimentation can be found in Appendix B 6. Conclusion The primary objective of the project was achieved, namely the new system is up and running at the Experimental Solar Plan. The separation of concerns data collection and analyses provides robust interface for continues data collection and on demand data analyses. Specifically, the fetcher (data collection) and be run at any given point in time for as long as needed; on the other hand, the data analysis works independently so data could be analyzed in both real time and/or at a later point. The system could be extended by adding robust data analyses functionality, but the current graphics interfaces could be reused. Also, in experiments showed that MongoDB has better overall performance than MySQL, since the MySQL writes are very slow compared than MongoDB writes, but MySQL reads were slightly faster. However, MongoDB provided better optimal performance. SolarCloud Rapid Data Logging 34

35 7. References: [1] Brown University Data Managment and Reserach Group, "MongoDB Database Design Research," Brown University, [Online]. Available: [2] Canonical Ltd., "Home Ubuntu," [Online]. Available: [Accessed ]. [3] 10gen, Inc., "MongoDB," 10gen, Inc., [Online]. Available: [Accessed ]. [4] Wikipedia, "Row (database)," [Online]. [5] K. Chodorow and M. Dirolf, MongoDB The Definitive Guide, O'Reilly, [6] T. Talov, "Solar Plant Data Logging," [7] Campbell Scientific. Available: SolarCloud Rapid Data Logging 35

36 Appendix A Experimentation <?php echo'<!--- INSERT ---->'; echotime_elapsed(); // Configuration $dbhost = 'localhost'; $dbname = 'test'; // Connect to test database $m = new Mongo("mongodb://$dbhost"); $db = $m->$dbname; // Get the users collection $c_users = $db->users; // Insert this new document into the users collectionf for($i=0; $i<1000; $i++){ // $c_users->save($user) $users = array( 'first_name' => $i, 'last_name' =>'Fan'.$i ); $c_users->save($users); } echotime_elapsed(); $con=mysqli_connect("localhost","root","","foo"); // Check connection if(mysqli_connect_errno()) { echo"failed to connect to MySQL: ". mysqli_connect_error(); } for($i=0; $i<1000; $i++){ mysqli_query($con,"insert INTO persons (first_name, last_name) VALUES ('Peter', 'Griffin')"); } echotime_elapsed2().'\n'; echotime_elapsed(); echo'\n<!-- SELECT -->'; $db = $m->selectdb('test'); $collection = new MongoCollection($db, 'users'); SolarCloud Rapid Data Logging 36

37 echotime_elapsed(); mysqli_query($con,"select * FROM persons"); echotime_elapsed2(); functiontime_elapsed() { static$last = null; $now = microtime(true); if($last!= null) { echo'<!-- MongoDB: '. ($now - $last).' -->'; } $last = $now; } functiontime_elapsed2() { static$last = null; $now = microtime(true); if($last!= null) { echo'<!-- MySQL: '. ($now - $last).' -->'; } } $last = $now; SolarCloud Rapid Data Logging 37