On October 23rd, 2014, we updated our
By continuing to use LinkedIn’s SlideShare service, you agree to the revised terms, so please take a few minutes to review them.
Hierarchical file Key Value / Tuple Store BigTable (HSAM, HDAM) Eventually Consistent Key Value Store Parent node Column family Local autonomy Partition tolerant Graph Databases Horizontal partition Sharding E. DATA AND QUERY MODEL non-ACID (atomic, BASE (basically available, soft There is a lot of variety in the data models and query consistent, isolated, state, eventually consistent) APIs in NOSQL databases. durable) Table 2: Data and Query Model TableB. CHARACTERISTICS NOSQL normally doesn’t have an ACID property like(atomicity, consistency, isolation, durability), no join Data Model Query APIoperation, special of the NOSQL is schema-free, replication Cassandra Column family Thriftsupport, easy API, eventually consistency, and more. So the CouchDB Document Map/reduce viewsmisleading term "NOSQL" (the community now translates it HBase Column family Thrift,RESTmostly with "Not Only SQL"). And it is structured storage and MongoDB Document Cursorusually has a collection of tables with structured data (most Neo4J Graph Graphprobably like a hash table or a dictionary) then no need to map Redis Collection Collectionobject-oriented designs into a relational model.Examples: Riak Document Nested hashesGoogle’s BigTable, Amazon’s Dynamo.Cassandra (used in Scalaris Key/Value Get/putFacebook’s inbox search) and HBase (Apache) are open Tokyo Key/Value Get/putsource. CabinetC. CAP THEOREM AND NOSQL Voldemort Key/Value Get/put F. PERSISTENCE DESIGN Table 3: Data Storage Design Table Consistency Persistence Design Cassandra Memtable/SSTable CouchDB Append-only B-tree HBase Memtable/SSTable on HDFS MongoDB B-tree Neo4J On-disk linked lists Redis In-memory with background snapshots Scalaris In-memory only Availability Partition Tokyo Cabinet Hash or B-tree Voldemort Pluggable(primarily BDB Tolerance MySQL) This are many number of persistence design avail today Figure 1: CAP Theorem Satisfaction but above I give some famous model. It gives you a various choice to implement NOSQL depend on your need here below I take one GRAPH model Neo4J to give an view about that CAP (FOR NOSQL DATABASES)( FOR EASY from that we can able to analyses the scenario and implementSCALABILITY) on it. CONSISTENCY: All database clients see the same data, III. GRAPH MODELeven with concurrent updates. Graph database it stores the value of nodes, edges and AVAILABILITY: All database clients are able to access properties. There are some general graph database aresame version of the data and easy scalability available that stores any graph and some special kinds of PARTITION TOLERANCE: The database can be split over graph database are also available like triple store and networkmultiple servers. database.D. CORE NOSQL SYSTEMS In network database it uses edges and nodes to represent NOSQLS Systems where many in types but these where and store the data. Graph database is faster when compare tothe core types of NOSQL Systems the relational database it map more directly to the structure ofStore / Column Families object-oriented applications And they successfully implemented in.Document Store Social networking 196
Represent the real world secondNode.setProperty( "message", "Raju" ); relationship.setProperty( "message", " son" ); Is the one of the best NOSQL type to make mind mapping The graph will look like this:from that we can able mapping the brain and forming a fuzzybased intelligence. (firstNode )---KNOWS--->(secondNode) Printing information from the graph: System.out.print( firstNode.getProperty( "message txt" ) );A. EXAMPLE System.out.print( relationship.getProperty( "message txt" ) );Node firstNode = graphDb.createNode(); System.out.print( secondNode.getProperty( "messagetxt" ) );Node secondNode = graphDb.createNode(); eg. Neo4j Printing will result in:Relationship relationship = Arun son RajufirstNode.createRelationshipTo(secondNode,MyRelationshipTypes.KNOWS );eg. Neo4jfirstNode.setProperty( "message", "Arun, " ); IV. OUR PROPOSAL SYSTEM NOSQL ON HUMANOID BRAIN FIGURE 2: IMPLEMENTATION OF NOSQLON HUMANOID ARTIFICIAL BRAINA.HUMANOID FUNCTIONALITY the given task and we need an instructions need to be frame it. Robot electronic system it can’t recognize human speech If we pass multiple pieces of Instructions to move a hand itselfand image. it can repose only to the binary number. Generally we need a multiprocessor system to process all thosethe binary digits are eight bits in length. In robot instructions instructions, assume that the robot has various parts that madeare spited into many pieces and stored in many places because to work to perform a task. The situation is seemed to be morethe instruction are in a form of chains, if one instruction starts complex, to resolve this conflict we going to provide ait continued by another instruction, to explain briefly the solution for this, instead of passing group of instructions, therobot parts are divided into pieces, for example take a hand it instructions are passed based on the task it will first call onehas following parts modified spiral joint, revolute joints, instruction and it address another instruction then it continuesspherical joint, phalanges, knuckles etc. if we want to take an until all instructions are passed if we want to follow thisobject or a particle we need to move all these parts to perform mechanism we need an effective database to handle with this much of instruction. 197
B. More memory using NOSQL column family’s concept the Column keys are grouped into Nowadays NOSQL is the popular non-relational database sets called column families, which form the basic unit ofit can handle with terabytes of data, it has an time stamp access control. All data stored in a column family is usually ofmechanism so that it queries current data without need of any the same type. By using this concept we spilt the instructionsspecial query to retrieve the latest information, it is very based on the task and the portion need to be moved, so that wehelpful in the robots because the robots will scan and updates can easily organize the data’s (instructions) in columnthe data’s regularly so that the time stamp mechanism helps to families, so that with the help of one object we can easily referreduce the processing time. In NOSQL database it has a the entire object based on the task. Figure 3: NOSQL DB Model for Robotic instruction Figure 4: NOSQL BD Model for Robotic instruction Information: Grouping of instruction for thumb (back node) 198
A. Master Node V. MAP REDUCES IN ROBOTICS The master node takes the input and it assigns the work Map reduce is the framework for processing the large to the clients.problems, it is need in robots because robots can scan large B. Reduce Step In the reduce step the result are combinedimage and it will try to stored it in database at that time the and given to the master node from that figure 5 you canDatabase finds difficulty to break the image into pieces and easily get idea about that.store the respected set. If suppose the robot made a query to C. ImportanceMatch the current scanning image with the database at that Above will explain you about the data management andtime the database find difficulty to combine the data’s that are retrieve capacity of NOSQL but this Map Reduce give astored, so that it need to focus more on queries to remove all massive performance in terms of input and output processthis drawbacks map reduce was introduced it helps to divide from NOSQL.the problems into many pieces and it given to the severalworker node. Figure 5: MAP REDUCE PROPOSAL SYSTEM MODEL ON ROBOTICS happens immediately when you do this. E.g. like updating the VI. ADVANTAGES OF OUR NOSQL cricket score after updating it immediately publishes that info IMPLEMENTATION ON ROBOTICS and replace the old score NOSQL is schema-free databases so it is easy to It has ability to handle billions of objects so weimplement and maintain, it can scale up and down, these improve the vision intelligence and hearing intelligence so it isdatabases are replicated to avoid fault-tolerant and can be the major step to produce humanoid with very high sensitivepartitioned if it scales large, the data are easily distributed tothe databases, it can process large amount data within a short intelligence. E.g. the database used for Amazon S3, which asperiod of time, it supports specific problem/situation that are of March 2010 was hosting 102 billion objects.no need to think in terms of relations but in terms given in asituation(e.g. documents, nodes,...) in most cases it is freely VII. CONCLUSIONSavailable because in most of the products are open-source. In future NOSQL based humanoids will play a vital role to serve the human beings. It will replace the pilots and we can First we don’t go with huge data server so it gives use it in the laboratories. We can also replace human by robotsconsume cost and it also have ability to consume power, from from the dangerous work like nuclear power plants and atomicthis proposal you can able to achieve superfast because we can researches. It will be intelligent, do and learn their work andsplit the input and Output easily using this map reduce concept react much faster than your CPU’s in home. You can use it asfrom that we easily go with cloud computing. a multipurpose person like security, driver, cook, servant, etc. Then the concept time stamp we easily update our robots And we may predict it will take part in all living houses andwithout any redundancy of data so we easily avoid garbage national services.collection and give automation to unwanted information In the part of global warming we can avoid number ofdeletion and the important thing is the updating process sensors and E-wastages like HDD, PC’s because it will act 199
like your personal assistant, Driver, Security. From NOSQL  FRENCH, C. D. One size _ts all database architectures do notwe can easily achieve the new era of humanoids. work for DSS. In Proc. of SIGMOD (May 1995), pp. 449.450.  AWLICK, D., AND KINKADE, D. Varieties of concurrency ACKNOWLEDGEMENT control in IMS/VS fast path. Database Engineering Bulletin 8, 2 (1985), 3.10. The authors are grateful to Dr. S. Kannan Advisor of  GHEMAWAT, S., GOBIOFF, H., AND LEUNG, S.-T. Theproject6thsense and to all team members of project6thsense Google _le system. In Proc. of the 19th ACM SOSP (Dec. 2003), pp. 29.43.for the making of our entire research projects.  GRAY, J. Notes on database operating systems. In OperatingSystems . An Advanced Course, vol. 60 of Lecture Notes REFERENCES in Computer Science. Springer-Verlag, 1978.  GREER, R. Daytona and the fourth-generation language  ABADI, D. J., MADDEN, S. R., AND FERREIRA,M. C. Cymbal. In Proc. of SIGMOD (1999), pp. 525.526. Integrating compression and execution in columnoriented database  HAGMANN, R. Reimplementing the Cedar _le system systems. Proc. of SIGMOD (2006). using logging and group commit. In Proc. of the 11th  AILAMAKI, A., DEWITT, D. J., HILL, M. D., AND SOSP (Dec. 1987), pp. 155.162. SKOUNAKIS,M. Weaving relations for cache performance. In  HARTMAN, J. H., AND OUSTERHOUT, J. K. The Zebra The VLDB Journal (2001), pp. 169.180. striped network _le system. In Proc. of the 14th SOSP  BANGA, G., DRUSCHEL, P., AND MOGUL, J. C. Resource (Asheville, NC, 1993), pp. 29.43. containers: A new facility for resource management  KX.COM. kx.com/products/database.php. Product page. in server systems. In Proc. of the 3rd OSDI (Feb.  LAMPORT, L. The part-time parliament. ACM TOCS 16,2 (1998), 1999), pp. 45.58. 133.169.  BARU, C. K., FECTEAU, G., GOYAL, A., HSIAO,H.,  MACCORMICK, J., MURPHY, N., NAJORK, M., THEKKATH, JHINGRAN, A., PADMANABHAN, S., COPELAND,G. P., AND C. A., AND ZHOU, L. Boxwood: Abstractions as the foundation WILSON, W. G. DB2 parallel edition. IBM Systems Journal 34, 2 for storage infrastructure. In Proc.of the 6th OSDI (Dec. 2004), pp. (1995), 292.322. 105.120.  BAVIER, A., BOWMAN, M., CHUN, B., CULLER, D.,KARLIN,  MCCARTHY, J. Recursive functions of symbolic expressions and S., PETERSON, L., ROSCOE, T., SPALINK, T., AND their computation by machine. CACM 3, 4 (Apr.1960), 184.195. WAWRZONIAK, M. Operating system support for  Database Fundamentals. Robert J. Robbins, planetary-scale network services. In Proc. of the 1st NSDI (Mar. Johns Hopkins University, firstname.lastname@example.org 2004), pp. 253.266.  NOSQL-databases.org  BENTLEY, J. L., AND MCILROY, M. D. Data compression  http://books.couchdb.org/relax/intro/eventual-consistency using long common strings. In Data CompressionConference  http://www.rackspacecloud.com/blog/2009/11/09/NOSQL- (1999), pp. 287.295. ecosystem/.Jonathan Ellis.  BLOOM, B. H. Space/time trade-offs in hash coding with  http://blog.evanweaver.com/articles/2009/07/06/up-and-running- allowable errors. CACM 13, 7 (1970), 422.426. with-cassandra/  BURROWS, M. The Chubby lock service for loosely coupled  http://horicky.blogspot.com/2009/11/NOSQL-patterns.html, distributed systems. In Proc. of the 7th OSDI  http://www.slideshare.net/Eweaver/cassandra-presentation-at- (Nov. 2006). NOSQL  CHANDRA, T., GRIESEMER, R., AND REDSTONE, J. Paxos  Bigtable:A Distributed storage system for structured data made live . An engineering perspective. In Proc. of PODC (2007). ,google,Inc,OSDI 2006.  COMER, D. Ubiquitous B-tree. Computing Surveys 11, 2 (June  Map Reduce: Simplified Data processing on large cluster, Google, 1979), 121.137. Inc.  COPELAND, G. P., ALEXANDER, W., BOUGHTER, E. E., AND KELLER, T. W. Data placement in Bubba. In Proc. of SIGMOD (1988), pp. 99.108.  DEAN, J., AND GHEMAWAT, S. MapReduce: Simpli_ed data processing on large clusters. In Proc. of the 6th OSDI (Dec. 2004), pp. 137.150.  DEWITT, D., KATZ, R., OLKEN, F., SHAPIRO, L., STONEBRAKER, M., AND WOOD, D. Implementation techniques for main memory database systems. In Proc. of SIGMOD (June 1984), pp. 1.8.  DEWITT, D. J., AND GRAY, J. Parallel database systems: The future of high performance database systems.CACM 35, 6 (June 1992), 85.98. 200